Меня зовут Алексей Гавриш, я — консультант по информационной безопасности. Я — человек, который задаёт вопросы, но редко получает ответы, умею играть на гитаре и вышивать крестиком :-)
Страх
Страх парализует. Нам всегда страшно, даже когда кажется, что нет. Наш мозг всегда хранит то, чего мы боимся. Наш мозг боится вне зависимости от нашего осознания этого, тем самым предохраняя нас от смерти. Мир изменился, а мы и наш мозг — ни капельки. Мне всегда казалось странным, почему люди не видят картину в целом. И лишены возможности составить какой-нибудь «план хотя бы на смехотворно короткий срок, ну, лет, скажем, в тысячу, но не могут ручаться даже за свой собственный завтрашний день». Спустя 40+ лет чтения книг умных людей нашей планеты пришло понимание, что такова природа человека.
То, что делает человек по природе своей, — случайно. И это принципиально.
Связанная с этим проблема неэргодичности процессов в экономике и в управлении — среднее по времени (ансамблю) и НЕ равно среднему статистическому. Есть еще и такая проблема: Системати́ческая оши́бка вы́жившего или просто ошибка выжившего (англ. survivorship bias) — разновидность систематической ошибки отбора, когда по одной группе объектов (условно называемых «выжившие») данных много, а по другой («погибшие») — практически нет. В результате исследователи пытаются искать общие черты среди «выживших» и упускают из вида, что не менее важная информация скрывается среди «погибших». Таким образом, ошибка выжившего — тенденция обращать внимание только на истории успеха, создающая искажённую картину, игнорирующую опыт неудачников и выбывших.
Обычно обсуждаются в жизни и в докладах на разных конференциях "истории успеха" в решении той или иной задачи, разработке новой "фичи" или нового продукта, но редко — неудачи или полные факапы. Это неприятно, не правда ли :-)
Казалось бы, что многие вещи очевидны, но на практике это не так, и в какой-то момент я решил свои мысли по этому поводу изложить в форме «вредных советов», адресованных тем, кому страшно делать хорошую Систему, но не страшно получить максимальное количество денег от Заказчика.
Итак: «Вредные советы» для владельцев компаний-интеграторов, разработчиков, руководителей проектов и архитекторов информационных систем.
Концепция
1. «Безысходные» данные — это состояние неопределённости набора данных, необходимых для разработки проектных решений на Систему. Чтобы «схлопнуть» состояние неопределённости, вам придётся самому придумать эти данные, никто всё равно проверять не будет, а нужны они именно вам.
2. Никогда сами не выбирайте место размещения Системы. В облаке ли она будет, или в ЦОДе каком. Это — головная боль Заказчика и ваших ИБшников. Пусть горят в аду, твари!
Бюджет
3. Когда планируете бюджет проекта, забудьте о том, что в вашей компании есть и другие производственные подразделения кроме заказной разработки ПО, готовые вам помочь создать идеальную Систему для Заказчика. Ведь с ними придется делиться! Не спрашивайте, сколько стоят их работы, и не отдавайте им ни копейки! Вы и только вы создаёте ценность для компании и актив для Заказчика. Гордитесь собой!
4. Никогда не привлекайте в проект главного архитектора и уж тем более не создавайте совет архитекторов. Эти бездельники только сожрут бюджет проекта. Да кому вообще нужны эти дураки?! Даже непонятно, за что им зарплату платят!
5. Всегда уговаривайте Заказчика делать не одну систему, а много маленьких. Так проще получить деньги. И еще потом можно отдельно взять деньги за то, чтобы эти маленькие системы заработали как одна.
6. Никогда не говорите Заказчику, сколько будет стоить система под ключ. Пусть радость от итоговой суммы придет к Заказчику уже в конце проекта.
7. Всегда идите на встречу Заказчику при просьбе подсчитать стоимость Системы защиты «под ключ» с последующим заключением договора на эту сумму. А что тут такого! Любые меры защиты, на которые не хватило денег, и автоматизацию процессов всегда можно заменить таджиками, которым платить не надо, а можно просто закопать их в лесу, когда работа будет закончена.
Планирование
8. Не вздумайте писать сквозной план-график проекта по созданию Системы с зависимостями. А если все же написали, ни при каких условиях не показывайте его Заказчику. Во-первых, это слишком сложно. Да и к тому же вас можно будет обвинить, что вы что-то просрали.
9. Нанимайте только тех руководителей проектов, которые никогда не работали в ИТ и не умеют учиться. Особенно на большие проекты. И вообще! Чем больше РПшников, тем эффективнее проект. Зуб даю.
10. Никогда не спрашивайте у функционального Заказчика, что он хочет получить в итоге. Это лишнее! Ведь вы точно знаете сами, что ему нужно.
11. При создании Системы всегда заключайте отдельные контракты на проектирование ее разных уровней (прикладное программное обеспечение, информационная безопасность, сети, железо, виртуализация, специфические услуги и т.д.). Какой-то из них наверняка выгорит и не утащит в минус остальной проект и "ебеду" вашего любимого департамента в случае создания Системы единым контрактом. И вы не окажетесь крайним.
12. Даже не пытайтесь переживать за результат проекта. Оно вам надо? Главное получить деньги. Акты подписали и разбежались.
Управление
13. Никогда не общайтесь по проекту с персоналом компании ниже директора департамента. Эти букашки ничего не понимают в вашем бизнесе.
14. Никогда не говорите с руководством компании о том, что в проекте, в котором вы участвуете, есть какие-то проблемы, которые вы не можете решить сами и вышестоящее руководство. Не отвлекайте руководителя по пустякам от расчёта прибыли компании и своей собственной премии.
15. Всегда следите, чтобы сотрудники группы/департамента ИБ интегратора были загружены. Например, если у них нет исходных данных для проектирования или аналитики, то срочно выдайте им новую задачу, а старую не отменяйте. Сотрудник справится, документы по системам писать — не сваи заколачивать. Там же всё одинаково — буковки и циферки какие-то, так можно и по сто проектов одновременно делать одним сотрудником! А не справится, наймём нового.
16. Раз в полгода или год меняйте команду разработчиков (причину можете придумать сами: долго, дорого, тупые, есть лучше и дешевле и т.п.), а после увольнения повышайте в должности руководителей и архитекторов этого проекта с повышением зарплаты. Да, проект затянется на годы, но зато результат в виде выплаченных премий и несделанного проекта не заставит себя ждать.
Проектирование
17. Никогда не сопоставляйте требования на подсистемы на предмет противоречий с бизнес-процессами Заказчика. Не тратьте время зря, ведь вам и так понятно, какой функционал нужен в каждой подсистеме. Все у вас получится!
18. Даже не вздумайте делать сквозные бизнес-процессы! Вы и без этого прекрасно видите результат.
19. Всегда выдавайте архитектуру ПО за архитектуру Системы. Главное, что вы "автоматизировали" процессы, описанные в ТЗ. Да и к тому же вы не знаете, как у Заказчика устроен ЦОД, и есть ли он вообще. Заказчик умный, сам допроектирует, ну или заставит это делать кого-нибудь еще за отдельные деньги.
20. Всегда делайте только то, что прописано в ТЗ к договору в качестве отчётных документов. Например, прописано, что нужна модель угроз и нарушителя на Систему или техпроект с рабочкой, сделайте это, и не важно, что у вас нет объекта моделирования. Вы же профессионал! Можете придумать сами и Систему, и условия её функционирования и размещения, в крайнем случае описать со слов Заказчика. Всё равно кроме Заказчика ваши документы никто читать не будет.
21. Никогда не пытайтесь убедить Заказчика, что предложенное им для проекта оборудование или ППО — говно и не соответствует ни требованиям регуляторов, ни требованиям производительности. Так у вас всегда будет повод обвинить в ваших косяках и задержках проекта либо самого Заказчика, либо выбранного им вендора.
22. Никогда не проявляйте инициативу на проекте и не пытайтесь сделать оптимальнее и качественнее. Догадываетесь почему? Потому что все равно наградят непричастных и накажут невиновных, да и о премии можно будет забыть, ведь вы расходовали свой ресурс не на те задачи, которые придумал руководитель проекта, а он точно знает, что важно для реализации проекта, а что нет. Про Систему ему обычно думать некогда, у него в списке таких задач нет.
23. Никогда не давайте сотрудникам ИБ участвовать в смежных задачах по созданию систем или приклада и инфраструктуры. Пусть делают своё ИБ и не тревожат вас дурацкими вопросами. У них вот и контракт отдельный, пусть с подписанными актами от Заказчика приходят!
24. Никогда не давайте «лишнюю», по-вашему мнению, информацию о проекте вендорам, которые участвуют в проекте, даже если они сами просят. Ни к чему им знать, что вы собираетесь делать с их оборудованием или ПО. Вы сами хотите насладиться вместе с Заказчиками всеми лудами и прочими граблями.
Внедрение
25. Всегда урезайте сроки внедрения Системы в 10 раз. Внедрение — это праздник. Вашим сотрудникам должно быть за честь внедрить систему быстро и без костылей. Настраивать Систему — это же всегда проще и безопасней, чем в шахте уголь добывать!
26. Никогда не запрашивайте условия эксплуатации оборудования у производителя до сдачи проекта. Нафиг надо! Вдруг то, что вы уже "продали" Заказчику, ему не подходит.
Эксплуатация
27. Всегда помните, что главное в Системе — тот код, который пишет ваша команда разработчиков. А то, на чем он будет работать и где, — это проблема Заказчика, вы же дадите ему сайзинг!
28. Если ваша команда ИБ (интегратора) выросла, да и на удалёнке работает половина, никогда не общайтесь друг с другом даже на одном проекте — пусть каждый знает своё место! Пусть консалтеры пишут справки и модели, инженеры пишут проекты, группа безопасной разработки проверяет код, сотрудники SOC мониторят, а инженеры внедрения и эксплуатации протирают контакты спиртом. В противном случае и качество продуктов повысится, и стоимость сотрудников тоже. Такое никак нельзя допустить, ваша компания пишет ПО, а не занимается ИТ и ИБ!
Ненависть
А про ненависть ничего не будет. Ну как можно ненавидеть такого милого котёнка — у него же лааапки :-)
P.S. Понятно, что мой опыт не единичен, поэтому в комментариях дополняйте своими «вредными советами» ;). Я планирую выпустить продолжение «вредных советов», и будут они посвящены регуляторам в области информационной безопасности и другим ведомствам, регулирующим деятельность, связанную с вопросами информационной безопасности.
Картинки созданы с помощью сервиса «Шедеврум» компании Яндекс.
