Ключевые выгоды

1. БЫСТРОЕ ОСВОЕНИЕ КОДА

Любой новый человек потратит на 20–30 % (а может и больше) времени меньше на погружение в код чем в код, который написан без конвенций.

2. ПОВЫШЕНИЕ КАЧЕСТВА И СНИЖЕНИЯ КОЛ-ВА ОШИБОК

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

3. ПОВЫШЕНИЕ СКОРОСТИ РАЗРАБОТКИ

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

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

Встроенное программное обеспечение (Embedded Software)

Не все программы стоят отдельно от датчиков и устройств. Многие программы устанавливаются сразу в микросхему устройства и становятся неотделимым целым от девайса, т. е. встроенным (embedded). Основное отличие от обычных программы, к которым мы привыкли их называют application software заключается в том, что:

1. ES работает только под конкретное устройство (например чайник, который измеряет температуру воды и сканирует, распознает, а что же за чай вы засыпали в него)

2. ES созданы, чтобы выполнять конкретную задачу.

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

4. ES часто работает без операционной системы и других приложений

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

ES приложение часто представляет собой Embedded computer

Часть 6. Карта технологий

Любую компанию можно представить в виде операционной модели, в которой есть набор функций, которые выполняются внутри этой компании. Например “Работа с клиентами”, “Бухгалтерия” и т.д. В этой операционной модели есть 3 уровня или слоя, как в пироге, это:

1. Фронт офис (от англ. “front”, т. е. спереди), там, где вы работаете с клиентами. Тут будут все функции и процедуры, которые касаются клиентов.

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

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

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

В проектировании, эти кубики называются Use Case (или сценарии использования технологии), в Agile, они носят название User Story (пользовательские истории) и т.д. Сам термин Use Case возник в языке UML (Unified Modeling Language – унифицированный язык проектирования). Этот открытый язык появился в период с 1984 по 1995 год, и стал активно использоваться в качестве, лучших практик моделирования и создания технологии. Любая технология решает определенные Use Case. Не больше, ни меньше. Я буду часто к этой аксиоме возвращаться, чтобы вы это запомнили. Нет универсальной технологии, каждая решает конкретные задачи. Если в вашей компании, технология не работает, а в другой компании работает, а это точно так, иначе бы технология не существовала, то видимо вы ее неправильно используете. В части кейсов, в мире появилось большое количество функциональных систем, которые заточены делать конкретную функцию, например управлять процессами (системы типа BPM) или управлять рисками внутри организации, например кредитными или операционными (такое семейство технологии можно назвать Risktech). Как вы заметили, название того или иного семейства технологий складывается из 2х слов, это “названия предметной области” + “tech”, краткого от англ. technology (технология). Часть таких акронимов вы, наверное, не слышали, например API Tech (технологии для управления интеграцией), а другие возможно слышали HR Tech (технологии в управлении персоналом – HR). Я специально все типы технологий привожу к единому знаменателю, чтобы вам было проще ориентироваться в них. Задача этой книги, не помочь вам выучить, все эти технологии, а помочь вам ориентироваться во всем этом множестве. Все эти названия, они не конечные, их можно дробить на подклассы, придумывать новые названия. Но в целом, это некий такой нулевой уровень, на мой взгляд с которого все начинается, и который является общим для 99 % компаний. Если не верите, можете взять свою компанию и попробовать составить для нее b-map.

Давайте попробуем разобрать, этот разноцветный ковер.

Process Tech

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

1. Технологии, которые позволяют управлять процессом (ВРМ)

2. Технологии, которые позволяют автоматизировать простое действие в процессе (роботизация)

3. Технологии, которые изучают эффективность процесса (Processes Mining)

BPM

ВРМ (бипиэм читается:), появились на пороге прошлого столетия. Не система, конечно, а предпосылки. к тому, что любая организация – это прежде всего набор процессов. Хотя вы не поверите, но до сих пор есть люди, которые в это не верят, ну не будем их расстраивать:). 100 лет назад, компании были очень неповоротливыми, никто толком не изучал и не пытался их систематизировать. Первым человеком, кто это попробовал сделать, был Фредрик Тейлор, не путать с Бруком Тейлором, математиком, и основоположником теоремы Тейлора, который жил лет на 250 раньше. Ф. У. Тейлор был замечательным инженером и придумал систематизацию труда. Фактически он утверждал, что любой труд может быть систематизирован и проанализирован, из-за чего Тейлор подвергался нападкам и компании всеобщего презрения. Профсоюзы не любили его за то, что он раскрывал секреты их мастерства и рассказывал из чего же строится процесс на работе, а капиталисты не любили за то, что он считал, что оптимизация процессов должна приносить доход рабочим, а не владельцам компаний. В общем все его называли “смутьяном”, представляете. Сейчас, спустя 100 лет, смутьяном назовут того, человека, кто захочет противиться систематизации процессов. Вот все неоднозначно. Угадайте, кто был первым применил практики и теорию Тейлора на практике? Это был Генри Форд. Сейчас конвейер Генри Форда, считается эталоном в области построения конвейерного производства, а 100 лет назад, его тоже считали сумасшедшим. Тейлор написал, интересный труд, под названием “Принципы научного менеджмента”, где описал, что одна из основных целей внедрения эффективной организации труда в компании, это рост доходов, как самого предпринимателя, так и работников. Т. е. технология позволяет зарабатывать 2м классам, 1) предпринимателю, 2) рабочему классу, в частности рост их благосостояния (well-being, так звучит благосостоянии на англ. языке). Это очень интересный термин, что означает благосостояние сейчас? Фактически это символ процветания соответствующей социальной группы. Тейлор считал, неправильным потребность предпринимателя получить максимальную прибыль со своих рабочих, за счет максимизации их труда. Что такое благосостояние для предпринимателя? Это получить максимальную прибыль. А для рабочего, это получить максимальную производительность без доп. затрат. Как вы, наверное, догадались, это можно достичь, лишь только тогда, когда работа осуществляется с минимальными затратами для обеих сторон. А значит, тут самое место для автоматизации. “Автоматом” называли в Древней Греции самодействующие механизмы, которые не требовали участия человека. Вернемся к Тейлору, помимо, наверное, очевидных выводов, он затрагивает интересный момент, который у него называется “недовыработка” или работа “с прохладой”, отсюда пошло слово “прохлаждаться”. Он говорит, что одни и те же люди играя в бейсбол могут показывать высочайшие результаты и будут стремится выиграть, но приходя на работу их работа не будет содержать той самой мотивации. Исключая вот такую вот “медленную” или “неинтересную” работу, он считал, что можно в 2 раза повысить производительность труда, количество выпускаемой продукции и т.д. Причины, по его мнению, которые способствуют распространению такой вот “прохладной” работы, является:

1. Опасение рабочих, что если они будут лучше и больше работать, то работы другим рабочим не останется, и поэтому других рабочих придется уволить.

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

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