А.П. Егоршин

Управление персоналом

Конспект лекций для преподавателя

Нижний Новгород

Егоршин А.П.

Управление персоналом: Конспект лекций. – Н.Новгород: НИМБ, 2005. – 136 с.

Содержит основные термины и определения, концептуальные схемы и таблицы, методические положения, формулы и принципы, методы работы с персоналом, краткий отечественный и зарубежный опыт, резюме и контрольные вопросы по дисциплине «Управление персоналом».

В главе 1 «Система работы с персоналом» рассмотрены вопросы: концепции управления персоналом; кадровая политика; подбор, оценка, расстановка, адаптация и обучение персонала.

В главе 2 «Организация работы с персоналом» изложены философия организации, структура персонала, регламентация управления, научная организация труда, основы лидерства и формирование коллектива.

В главе 3 «Мотивация, оплата и эффективность» рассмотрены вопросы мотивации и потребностей, оплаты труда персонала, методы управления, коммуникации и этикет, эффективность работы персонала.

Конспект лекций предназначен для преподавателей, читающих дисциплины «Основы управления персоналом», «Управление персоналом» и «Управление человеческими ресурсами».

Глава 1. Система работы с персоналом……………….…….………….. 5

1.1. Персонал как система……………………………………...…………... 5

1.2. Кадровая политика …………………………………………………….. 10

1.3. Подбор персонала ………………………………….………………….. 16

1.4. Оценка персонала ……………………………………………………… 22

1.5. Расстановка персонала ………………………………………………... 26

1.6. Адаптация персонала …………………………………………………. 32

1.7. Обучение персонала …………………………………………………… 36

Глава 2. Организация работы с персоналом ………………………….. 41

2.1. Философия организации …………………………….………………... 41

2.2. Структура персонала ……………………………………….…………. 44

2.3. Регламентация управления ………………………….………………... 52

2.4. Научная организация труда …………………………………………… 64

2.5. Основы лидерства ……………………………………………………... 72

2.6. Формирование коллектива ……………………………………………. 82

Глава 3. Мотивация, оплата и эффективность ……………………….. 89

3.1. Мотивации и потребности …………………………….……………… 89

3.2. Оплата труда …………..…………………………………….…………. 100

3.3. Методы управления …………………………………………………… 107

3.4. Коммуникации и этикет ………………………………………………. 116

3.5. Эффективность работы персонала ………………….………………... 124

Литература ………………………………………..…………….…………. 131

Правильный путь таков: усвой то, что сделали твои предшественники, и иди дальше.

Л.Н. Толстой

Концепция управленияперсоналом

	Государственноерегулирова-
Обучение	ниерынка трудовых ресурсов
Обучение	Классификация персонала
персонала		Кадровая политика
персонала	Анализконцепцийуправле-	Кадровая политика
Системароссийского	ния персоналом	Типывластивобществе
образования	Взаимосвязьподсистем	Стильруководства
Виды обучения	работысперсоналом	Концептуальные кадровыедо-
Профессиональнаяподготовка
Высшее образование		Современная кадроваяполитика
Повышениеквалификации		Качества российскогоработника
Переподготовка кадров		Принципыработы
Каквыбратьобразовательное		с персоналом
учреждение?

Адаптация		Подборперсонала
Адаптация		Подборперсонала
персонала		Расчетпотребности вперсонале
	с персоналом	Модели рабочих мест
Критерии адаптации персонала		Профессиональныйотборперсонала
Адаптация молодых специалистов		Собеседование
Наставничество и		Формированиерезервакадров
консультирование		Конкретная ситуация
Развитиечеловеческих ресурсов		«Доверяй, нопроверяй»
		Деловаяигра«Подбор

	Расстановка	персонала»
	Расстановка
	персонала	Оценка персонала
	Принципыиметоды	Оценка персонала
	Принципыиметоды
	расстановки персонала
	Типовые моделикарьеры	Методы оценки персонала
	Планированиекарьеры	Методы оценки персонала
	Планированиекарьеры	Аттестациякадров
	Условияиоплата труда	Аттестациякадров
	Условияиоплата труда	Деловаяигра«Аттестация»
	Движениеперсонала	Деловаяигра«Аттестация»
	Движениеперсонала
	Порядокувольненияперсонала
	Конкретная ситуация
	«Конфликт»

ГЛАВА 1. СИСТЕМА РАБОТЫ С ПЕРСОНАЛОМ

1.1. Персонал как система

Кадры решают все...

И.В. Сталин

Рынок трудовых ресурсов

Рынок труда − совокупность социально-экономических отношений между государством, работодателями и работниками по вопросу купли-продажи рабо-

чей силы, обучения работников и использования их в процессе производства.

Рынок рабочей силы − включает социально-экономические отношения за-

нятых и незанятых работников, т.е. все экономически активное население страны. Таким образом, в этот рынок включаются безработные.

Рынок трудовых ресурсов − совокупность социально-экономических отно-

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

тых, незанятых и учащихся).

Трудовые ресурсы – «население обоих полов в трудоспособном возрасте

(для мужчин в возрасте от 16 до 59 лет, для женщин – от 16 до 54 лет вклю-

чительно), за исключением неработающих инвалидов войны и труда I и II

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

собного возраста), занятые в экономике».

Совокупность понятий, регламентирующих рынок трудовых ресурсов, пока-

зана на рис. 1.1.1 учебника А.П. Егоршина «Управление персоналом» (стр. 10).

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

ления и государственных органов, показана на рис. 1.1.2 учебника А.П. Егоршина «Управление персоналом» (стр. 12) .

Термин «персонал» объединяет составные части трудового коллектива организации. К персоналу мы относим всех работников (трудовой коллектив), выполняющих производственные или управленческие операции и занятых переработкой предметов труда с использованием средств труда, рис. 1.1.1 (рис. 1.1.3 учебника А.П. Егоршина «Управления персоналом», стр. 15) . Понятия

«кадры», «работники», «персонал» идентичны, если за основу принять данное нами определение. В дальнейшем мы будем пользоваться термином «персонал» (personnel), используемым в государственном образовательном стандарте (ГОС) и наиболее принятым в отечественной и зарубежной практике.

ПЕРСОНАЛ

Производственный персонал

Управленческий персонал

(рабочие)

(служащие)

Основные

Вспомогательные

Руководители

Специалисты

Рис. 1.1.1. Классификация персонала

Рабочие , или производственный персонал, осуществляют трудовую деятельность в материальном производстве с преобладающей долей физического труда. Они обеспечивают выпуск продукции, ее обмен, сбыт и сервисное обслуживание. Производственный персонал можно разделить на две составные части: основной персонал – рабочие, преимущественно занятые в сборочных цехах предприятия; вспомогательный персонал – рабочие, преимущественно занятые в заготовительных и обслуживающих цехах предприятия.

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

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

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

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

Специалистов предприятия можно разделить на три основные группы в зависимости от результатов их труда:

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

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

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

Анализ концепций управления персоналом

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

Учитывая, что все перечисленные подходы к анализу роли человека в производстве представляют собой взгляды с разных сторон одного и того же явления, мы постарались классифицировать известные концепции в виде квадрата (рис. 1.1.4 учебника А.П. Егоршина «Управление персоналом», стр. 19 ).

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

Взаимосвязь подсистем работы с персоналом

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

Система работы с персоналом организации состоит из шести взаимосвязанных подсистем (рис. 1.1.5 учебника А.П. Егоршина «Управление персоналом», стр. 21).

Кадровая политика определяет генеральную линию и принципиальные установки в работе с персоналом на длительную перспективу.

Подбор персонала заключается в формировании резерва кадров на замещение вакантных рабочих мест.

Оценка персонала осуществляется для определения соответствия работника вакантной или занимаемой должности.

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

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

Обучение персонала предназначено для обеспечения соответствия профессиональных знаний и умений работников современному уровню производства и управления.

Система работы с персоналом отражается в таких важнейших документах, как: устав организации; философия организации; правила внутреннего трудового распорядка; коллективный договор; штатное расписание предприятия; положение об оплате и премировании труда; положение о подразделениях; контракт сотрудника; должностные инструкции; модели рабочих мест; регламенты управления и др.

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

Взаимосвязь подсистем работы с персоналом с нормативными документа-

ми предприятия показана на рис. 1.1.6 учебника А.П. Егоршина «Управление персоналом» (стр. 23).

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

2. Персонал объединяет все составные части трудового коллектива организации, выполняющие производственные или управленческие функции и занятых переработкой предметов труда с помощью средств труда.

3. Существуют 4 концепции управления персоналом: управление трудовыми ресурсами, управление человеческими ресурсами, управление персоналом, социальный менеджмент.

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

Контрольные вопросы

1. Какие понятия характеризуют рынок трудовых ресурсов?

2. Назовите основные компоненты простой модели рыночных отношений?

3. На какие основные группы разделяется персонал?

4. Назовите основные подсистемы работы с персоналом?

5. Назовите главные нормативные документы предприятия.

Как, всё-таки, разработать реально работающую систему KPI в компании? Методик много, есть отдельные примеры, а вот найти алгоритм разработки реальной системы KPI, практически, невозможно. Надеюсь, читателю будет интересен предложенный алгоритм разработки системы KPI «с нуля» (когда еще ничего нет), заканчивая финальным результатом - работающей системой. Об этом в данной статье.

«Бог не на стороне больших батальонов, а на стороне лучших стрелков».

Вольтер

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

KPI - Key Performance Indicators - ключевые показатели эффективности деятельности подразделения, компании или предприятия. В русской аббревиатуре используется сокращение «КПЭ».

Начну с главного. Вопросы, которые обычно возникают, следующие:

Где взять эти самые KPI, и какие они должны быть? Будут ли эти KPI достижимы, и как это определить?
Какие KPI важны, а какие нет?
Как с помощью KPI увязать ключевые сферы деятельности компании, да так, чтобы KPI для маркетинга не противоречили KPI для продаж?
Какую методологию реализации проекта использовать? Допустим, выбрали методологию Balanced Scorecard (BSC) - Сбалансированную систему показателей. Что нужно делать далее?
С чего начать такой проект, и чем он должен закончиться? И т.д.

Вопросов масса. Ответов, как обычно, в разы меньше.

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

Рассмотрим алгоритм создания системы KPI, когда стратегии развития бизнеса в компании нет. По шагам.

Шаг 1. Выбираем методологию реализации проекта создания системы KPI. Например, методологию Balanced Scorecard (BSC). Об этом я писал в статье «Как разработать «Штурвал руководителя»», но повторюсь. Это - классические 4 «стены». См. Рис.1. Суть коротко:

A. Финансы . Финансы в компании обеспечиваются, всё-таки, продажами товаров и услуг.
B. Продажи . Чтобы с продажами было всё нормально, нужны технологии/продукты - те, которые востребованы рынком и те, которые можно рынку предлагать (продавать).
C. Технологии/продукты . Чтобы с технологиями/продуктами было всё нормально, нужны специалисты - люди, которые их создают.
D. Люди . Чтобы люди (способные к этому) создавали конкурентоспособные продукты, им нужно платить, их нужно обучать и развивать и т.д. Тогда они будут создавать продукты, продукты будут продаваться, и у компании с финансами будет всё в порядке. Далее компания сможет снова и снова инвестировать в людей для создания новых технологий/продуктов. Технические специалисты (производственный персонал) реализуют проекты, за которые заказчики, собственно, и платят деньги.

Рис. 1. Очень упрощенно суть методологии Balanced Scorecard (BSC) - Сбалансированной системы показателей.

Шаг 2. Формируем структуру главных сфер деятельности компании. Например, для проектной компании - это:

«Стена» A

Набор более сложных макропараметров. Как-то: показатели ликвидности, структура капитала, рентабельность бизнеса, деловая активность и прочие в данной статье рассматривать не будем.

«Стена» B

2. Продажи .

3. Маркетинг .

«Стена» C

4. Ключевые направления развития (их состояние). Допустим, это - модернизация и расширение продуктовой линейки.

5. Пресейл .

«Стена» D

6. Производство (реализация проектов).

7. HR (управление персоналом).

Комментарий: стоит отметить, что многие компании добавляют к классическим 4-м «стенам» свои «стены» (5-ую, 6-ую), являющиеся важнейшими в деятельности компании. Например, логистический блок.

Шаг 3. Определяем те сферы, которые мы хотим усилить. Или сферы, по которым у нас есть явные «точки провалов». «Точки провалов» - это не полные провалы в бизнесе. Это - то, что не работает, или работает не очень хорошо. Задача понятна - ликвидировать «точки провалов». Такие «точки провалов» есть в каждой компании.

Пример задачи . Допустим, у нас, в целом, всё более-менее нормально, за исключением того, что Отраслевой Сегмент 1 перестал приносить прибыль, но мы видим, что перспективен Отраслевой сегмент 2 (или новая перспективная ниша), с которым нужно срочно начать работать.

Пример плана действий.

1. Подготовить/скорректировать продуктовую линейку для нового Отраслевого сегмента 2 (для краткости - новая отрасль - «НО»). Это - «стена» С.
2. Найти профессионального директора по продажам для «НО». Это - «стена» B и D, так как, это - задача для директора по продажам компании и для HR.

a. Разработать профиль клиента «НО». Это - «стена» B.

b. Разработать профиль директора «НО». Это - «стена» B.

c. Разработать основные параметры мотивации директора «НО». Это - «стена» B.

d. Разработать мотивационный лист директора «НО» и согласовать его. Это - «стена» D.

e. Осуществить поиск/хантинг директора «НО». Это - «стена» D.

3. Сформировать новый отраслевой департамент - для краткости - «НОД» - (бюджет, центры ответственности, штатное расписание и т.д.). Это - «стена» B.

a. Поставить задачи директору «НОД». Это - стена «B».

b. Разработать основные параметры мотивации продавцов «НОД». Это – «стена» B.

c. Разработать мотивационные листы продавцов «НОД» и согласовать их. Это - стена «D».

d. Осуществить поиск/хантинг продавцов в «НОД».

e. Перевести часть продавцов, часть принять на работу в «НОД», часть, возможно, уволить. Это - «стена» B и D.

4. Поставить задачи пресейл для продвижения решений компании в «НО». Это - «стена» D.

5. Поставить задачи маркетингу для продвижения решений компании в «НО». Это - «стена» B.

Пример дерева целей и KPI.

«Стена» С

KPI (Технического директора):

Подготовить/скорректировать продуктовую линейку для «НО».
Поставить задачи пресейл для продвижения решений компании в «НО».

«Стена» B

KPI (Директора по продажам компании):

Разработать профиль клиента «НО».
Разработать профиль директора «НО».
Разработать основные параметры мотивации директора «НО».
Сформировать «НОД» (бюджет, центры ответственности, штатное расписание и т.д.).
Поставить задачи директору «НОД» (после того, как HR найдёт директора).
Поставить задачи маркетингу для продвижения решений компании в «НО».

KPI (Директора «НОД»):

Разработать основные параметры мотивации продавцов «НОД». Согласовать их с директором по продажам компании и передать в HR.
Отсмотреть продавцов (существующих и новых), принять решения.

«Стена» D

KPI (Директора по HR):

Разработать мотивационный лист директора «НО» и согласовать его с Директором по продажам компании.
Осуществить поиск/хантинг директора «НО» (найти профессионального директора по продажам).
Разработать мотивационные листы продавцов «НОД» и согласовать их с директором «НОД».
Осуществить поиск/хантинг продавцов в «НОД».
Перевести часть продавцов, часть принять на работу в «НОД», часть, возможно, уволить.

Комментарий: понятно, что есть задачи и для «стены» A - спланировать новые расходы в бюджете компании и т.д.

Итак, мы сформировали дерево целей и поставили цели и задачи, которые обеспечат создание нового отраслевого департамента (НОД).

1. Департамент должен будет возглавить профессиональный в этой отрасли директор по продажам.
2. Мы спланировали все необходимые действия, связанные с закрытием, либо уменьшением в размерах Отраслевого направления 1 , если его пока закрыть нельзя.
3. Техническому департаменту, маркетингу, HR и пресейл поставлены соответствующие задачи, которые должны выполнить свою часть работы, согласно их профилю, и поддержать новое направление «по всем фронтам».

Уважаемый читатель, наверняка, подумает: «Легко сказать: взять на работу профессионального директора по продажам нового отраслевого сегмента!». Сложно! Как делал автор? Я формировал несколько списков для HR.

1. Cписок №1. Крупные и средние компании, в которых есть смысл искать директора или заместителя директора аналогичного направления. Не получается, тогда:
2. Список №2. Меньшие по размеру компании, в которых есть смысл искать директора. Человек будет немного на вырост, но он будет внутри более отстроенной компании. И для него это будет карьерный рост. Не получается, тогда:
3. Список №1. Искать в крупных и средних компаниях сильного продавца, а не менеджера. Также на вырост. Не получается, тогда:
4. Список №1. Искать близкого по отраслевому признаку директора, с учетом его способностей освоить новую отрасль.
5. И т.д. Были и другие варианты.

Кстати, служба HR, получив такие списки, довольно быстро могла уже и сама сориентироваться, где и кого искать. В итоге кандидаты обычно находились.

«Для человека, который не знает, к какой гавани он направляется, ни один ветер не будет попутным».

Луций Анней Сенека Младший

Детали KPI можно формировать, используя, например, широко известную методологию постановки целей S.M.A.R.T. Поэтому,

Шаг 4. Изучить методологию целеполагания, которая будет использоваться при постановке целей.

Например, методологию постановки целей S.M.A.R.T.

Идём дальше. Определили сферы, которые мы хотим усилить. Или сферы, по которым у нас точно есть «точки провалов». Что дальше? Далее мы разрабатываем план действий (см. пример выше), который позволит нам усилить эти сферы и/или ликвидировать «точки провалов». Без целостного плана действий, построить систему KPI, которая объединит работу различных служб компании, не реально. Во всяком случае, довольно сложно.

Шаг 5. Разработка плана действий.

На Шаге 3 я показал пример плана действий, не самого тривиального, но который вполне можно реализовать, и такие планы действий довольно часто компаниями реализуются. Что важно? - содержательный подход к решению задач!

Шаг 6. Проверка плана действий на выполнимость.

Опыт показывает, что чаще всего, сразу понятно, какие пункты плана точно выполнимы. Главное - нужно внимательно посмотреть на те пункты, которые явно вызывают сомнения. И либо, немного подумать (например, устроить «мозговой штурм»), либо привлечь экспертов, либо, возможно, пойти другим, более простым, путём. Но, не следует ставить явно невыполнимые (недостижимые) цели и задачи!

Шаг 7. Построение дерева целей (и задач).

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

Шаг 8. Формирование перечня KPI с назначением ответственных сотрудников за конкретные KPI.

Пример дерева целей и формирования перечня KPI на основе плана действий приведен в примере выше.

Шаг 9. Формирование мотивационных листов.

Вот пока в мотивационных листах не появятся аналогичные (приведенным выше) качественные цели (а в примере выше нет ни одной финансовой цели!), система KPI работать не будет! Она останется «на бумаге». То, что приведено в примере выше - это то, что нужно срочно делать! Ровно для того, чтобы не «наработать» кучу лишних затрат, и что еще хуже - убытков, и ровно для того, чтобы как можно быстрее обеспечить дальнейший рост компании. Разумеется, финансовый!

«Невозможно решить проблему на том же уровне, на котором она возникла.

Нужно стать выше этой проблемы, поднявшись на следующий уровень».

Альберт Эйнштейн

Как реализовать такой проект?

Я очень часто слышу «пробовали - не получается!». Довольно много причин, по которым такие проекты не доходят до стадии эксплуатации и финального результата.

Мы часто забываем, что человек - не машина. Поэтому на основании собственного опыта я бы рекомендовал следующее:

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

Далеко не всегда эффективно запускать крупный и сложный проект.

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

2. Небольшие пилотные проекты лучше делать в простейших и понятных средствах (например, в Word или в Excel). Для начала. Главное, это - содержательна часть таких проектов, «положенная на бумагу». При реализации совсем небольшой задачи сделанные ошибки (а они будут!) можно быстро исправить.

3. Провести полный цикл моделирования - от решения какой-то небольшой задачи, до формирования KPI с условным «назначением» ответственных и формированием условных мотивационных листов.

Пример. Допустим, в компании нет мотивационных листов (пока), нет системы KPI (пока), и ранее компания этот проект не реализовывала. Как смоделировать ситуацию? Выполнить пп.1-3. KPI не назначать (!), и мотивационные листы «не вручать» (!). Просто поручить ответственному менеджеру то, что для него прописано. А потом сравнить то, что было спланировано, и что реально получилось.

Крайне важно стараться избегать «классических» ошибок. Для этого нужно выполнять следующее:

1. Обязательно формировать конечные цели проекта по созданию системы KPI. Цель - «выставить KPI» - «понятна». Но это всё равно, что «повысить эффективность бизнеса», «обеспечить дальнейший рост компании» и т.д.

Приведу пример спектра практических целей создания системы KPI:

a. Цель 1.1: проверка компетенций менеджеров и ключевых сотрудников с целью выявления «точек провалов» (некомпетентных сотрудников) и перспективных сотрудников (способных расти). Всё-таки, ключевые показатели эффективности должны показывать (и показывают!) эффективность и неэффективность.

b. Цель 1.2: проверка эффективности сфер бизнеса компании (продажи, производство, пресейл, маркетинг и т.д.) с этой же целью.

c. Цель 1.3: проверка эффективности бизнес-процессов и коммуникаций в компании. Большинство крупных целей и задач реализуется силами различных подразделений. От слаженности их работы зависит рост компании. Не больше и не меньше! Это и есть та самая эффективность, о которой мы часто говорим.
2. План действий обязательно проверять на выполнимость. Чтобы в нём не было недостижимых целей (и задач).
3. Обязательно назначать ответственных за конкретные KPI. Хотя бы моделировать это (для начала). Чтобы не получалось так, что за конкретные KPI реально никто не отвечает.

«То, что является делом всех, не является ничьим делом » .
Изаак Уолтон
4. Проект по созданию системы KPI обязательно заканчивать мотивационными листами. Чтобы сформированные KPI не оказались «вне закона». Если это - пилотный проект, пусть это будет несколько KPI на период 2-3-4 месяца. Это - тоже правильно.

Практический пример на основе методологии Balanced Scorecard (BSC).
Пример приведу на основе вышесказанного, с учетом упомянутой методологии и в виде последовательности практических действий. Допустим, Вы начинаете с верхушки «Финансы» и Вас беспокоит показатель «маржинальность». Понятно, что способов повысить маржинальность проектов очень много, поэтому нет смысла перечислять все эти способы. Нужно выбрать способы, присущие вашей компании, а также выявить причины недостаточной маржинальности.
Итак, очень условный план - только для примера.
1. KPI-1. Повысить маржинальность проектов не менее, чем на 7% за период времени не более, чем 6 месяцев.
Допустим, ключевые причины недостаточной маржинальности проектов следующие (условно):

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

Отсюда «вырастают» KPI следующего уровня для ряда служб компании. А именно (снова - условно):

2. KPI-1-1 (для Технической дирекции и руководителей проектов (РП)): выполнение проектов в сроки и в рамках бюджета проекта. Выполнен KPI по проекту - РП получил бонус. Нет - нужно разбираться, почему, а, возможно, и менять РП.

3. KPI-1-2 (для Блока маркетинга): вычислить отрасли, сегменты и ниши, более платежеспособные, чем те, с которыми сегодня работает компания. Подготовить презентацию и обосновать свои предложения. В течение <такого-то срока>.
4. KPI-1-3 (для Блока продаж): сформировать портфель проектов объемом не менее <такого-то>, в течение не менее <такого-то срока> (в плотном взаимодействии с маркетингом, чтобы не терять время). Чтобы была возможность выбора проектов для реализации.
5. KPI-1-4 (для Блока закупок) пока нет. Первоначально можно поставить задачу – проработать и дать предложения, как уменьшить стоимость закупаемого оборудования под проекты.

Как, все-таки, разработать реально работающую систему KPI в компании? Методик много, есть отдельные примеры, а вот найти алгоритм разработки реальной системы KPI, практически, невозможно. Предлагаем алгоритм разработки системы KPI «с нуля» (когда еще ничего нет), заканчивая финальным результатом - работающей системой.

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

Начну с главного. Вопросы, которые обычно возникают, следующие:

Где взять эти самые KPI, и какие они должны быть? Будут ли эти KPI достижимы, и как это определить?
Какие KPI важны, а какие нет?
Как с помощью KPI увязать ключевые сферы деятельности компании, да так, чтобы KPI для маркетинга не противоречили KPI для продаж?
Какую методологию реализации проекта использовать? Допустим, выбрали методологию Balanced Scorecard (BSC) - Сбалансированную систему показателей. Что нужно делать далее?
С чего начать такой проект, и чем он должен закончиться? И т. д.

Вопросов масса. Ответов, как обычно, в разы меньше.

Рассмотрим алгоритм создания системы KPI, когда стратегии развития бизнеса в компании нет. По шагам.

Шаг 1. Выбираем методологию реализации проекта создания системы KPI

Например, методологию Balanced Scorecard (BSC). Это - классические 4 «стены» (рис. 1 ). Суть коротко:

A. Финансы . Финансы в компании обеспечиваются, все-таки, продажами товаров и услуг.

B. Продажи . Чтобы с продажами было все нормально, нужны технологии/продукты - те, которые востребованы рынком и те, которые можно рынку предлагать (продавать).

C. Технологии/продукты . Чтобы с технологиями/продуктами было все нормально, нужны специалисты - люди, которые их создают.

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

Рис. 1. Очень упрощенно суть методологии Balanced Scorecard (BSC) - сбалансированной системы показателей

Шаг 2. Формируем структуру главных сфер деятельности компании

Например, для проектной компании - это:

«Стена» A

1. Финансы . Простые параметры: доходы, расходы (оплата поставщикам, з/п, аренда, ставки по овердрафтам, потери по курсовым разницам, налоги и т. д.), прибыль и т. д.

Набор более сложных макропараметров. Как-то: показатели ликвидности, структура капитала, рентабельность бизнеса, деловая активность и прочие в данной статье рассматривать не будем.

«Стена» B

2. Продажи .

3. Маркетинг .

«Стена» C

4. Ключевые направления развития (их состояние). Допустим, это - модернизация и расширение продуктовой линейки.

5. Пресейл .

«Стена» D

6. Производство (реализация проектов).

7. HR (управление персоналом).

Комментарий : стоит отметить, что многие компании добавляют к классическим 4-м «стенам» свои «стены» (5-ую, 6-ую), являющиеся важнейшими в деятельности компании. Например, логистический блок.

Шаг 3. Определяем те сферы, которые мы хотим усилить

Или сферы, по которым у нас есть явные «точки провалов». «Точки провалов» - это не полные провалы в бизнесе. Это - то, что не работает, или работает не очень хорошо. Задача понятна - ликвидировать «точки провалов». Такие «точки провалов» есть в каждой компании.

Пример задачи . Допустим, у нас, в целом, все более-менее нормально, за исключением того, что Отраслевой Сегмент 1 перестал приносить прибыль, но мы видим, что перспективен Отраслевой сегмент 2 (или новая перспективная ниша), с которым нужно срочно начать работать.

Пример плана действий:

Подготовить/скорректировать продуктовую линейку для нового Отраслевого сегмента 2 (для краткости - новая отрасль - «НО»). Это - «стена» С.
Найти профессионального директора по продажам для «НО». Это - «стена» B и D, так как, это - задача для директора по продажам компании и для HR:

Разработать профиль клиента «НО». Это - «стена» B.
Разработать профиль директора «НО». Это - «стена» B.
Разработать основные параметры мотивации директора «НО». Это - «стена» B.
Разработать мотивационный лист директора «НО» и согласовать его. Это - «стена» D.
Осуществить поиск/хантинг директора «НО». Это - «стена» D.

Сформировать новый отраслевой департамент - для краткости - «НОД» - (бюджет, центры ответственности, штатное расписание и т. д.). Это - «стена» B:

Поставить задачи директору «НОД». Это - «стена» B.
Разработать основные параметры мотивации продавцов «НОД». Это - «стена» B.
Разработать мотивационные листы продавцов «НОД» и согласовать их. Это - «стена» D.
Перевести часть продавцов, часть принять на работу в «НОД», часть, возможно, уволить. Это - «стена» B и D.

Поставить задачи пресейл для продвижения решений компании в «НО». Это - «стена» D.

Поставить задачи маркетингу для продвижения решений компании в «НО». Это - «стена» B. И т. д.

Пример дерева целей и KPI

«Стена» С

KPI (Технического директора):

Подготовить/скорректировать продуктовую линейку для «НО».
Поставить задачи пресейл для продвижения решений компании в «НО».

«Стена» B

KPI (директора по продажам компании):

Разработать профиль клиента «НО».
Разработать профиль директора «НО».
Разработать основные параметры мотивации директора «НО».
Сформировать «НОД» (бюджет, центры ответственности, штатное расписание и т. д.).
Поставить задачи директору «НОД» (после того, как HR найдет директора).
Поставить задачи маркетингу для продвижения решений компании в «НО».

KPI (директора «НОД»):

Разработать основные параметры мотивации продавцов «НОД». Согласовать их с директором по продажам компании и передать в HR.
Отсмотреть продавцов (существующих и новых), принять решения.

«Стена» D

KPI (Директора по HR):

Разработать мотивационный лист директора «НО» и согласовать его с Директором по продажам компании.
Осуществить поиск/хантинг директора «НО» (найти профессионального директора по продажам).
Разработать мотивационные листы продавцов «НОД» и согласовать их с директором «НОД».
Осуществить поиск/хантинг продавцов в «НОД».
Перевести часть продавцов, часть принять на работу в «НОД», часть, возможно, уволить.

Комментарий : понятно, что есть задачи и для «стены» A - спланировать новые расходы в бюджете компании и т. д.

Итак, мы сформировали дерево целей и поставили цели и задачи, которые обеспечат создание нового отраслевого департамента (НОД):

Департамент должен будет возглавить профессиональный в этой отрасли директор по продажам.
Мы спланировали все необходимые действия, связанные с закрытием, либо уменьшением в размерах Отраслевого направления 1 , если его пока закрыть нельзя.
Техническому департаменту, маркетингу, HR и пресейл поставлены соответствующие задачи, которые должны выполнить свою часть работы, согласно их профилю, и поддержать новое направление «по всем фронтам».

Cписок № 1. Крупные и средние компании, в которых есть смысл искать директора или заместителя директора аналогичного направления. Не получается, тогда:
Список № 2. Меньшие по размеру компании, в которых есть смысл искать директора. Человек будет немного на вырост, но он будет внутри более отстроенной компании. И для него это будет карьерный рост. Не получается, тогда:
Список № 1. Искать в крупных и средних компаниях сильного продавца, а не менеджера. Также на вырост. Не получается, тогда:
Список № 1. Искать близкого по отраслевому признаку директора, с учетом его способностей освоить новую отрасль.
И т. д. Были и другие варианты.

Кстати, служба HR, получив такие списки, довольно быстро могла уже и сама сориентироваться, где и кого искать. В итоге кандидаты обычно находились.

Детали KPI можно формировать, используя, например, широко известную методологию постановки целей S.M.A.R.T. Поэтому шаг 4 .

Шаг 4. Изучить методологию целеполагания, которая будет использоваться при постановке целей

Например, методологию постановки целей S.M.A.R.T.

Идем дальше. Определили сферы, которые мы хотим усилить. Или сферы, по которым у нас точно есть «точки провалов». Что дальше? Далее мы разрабатываем план действий (см. пример выше), который позволит нам усилить эти сферы и/или ликвидировать «точки провалов». Без целостного плана действий, построить систему KPI, которая объединит работу различных служб компании, не реально. Во всяком случае, довольно сложно.

Шаг 5. Разработка плана действий

На Шаге 3 я показал пример плана действий, не самого тривиального, но который вполне можно реализовать, и такие планы действий довольно часто компаниями реализуются. Что важно - содержательный подход к решению задач!

Шаг 6. Проверка плана действий на выполнимость

Опыт показывает, что чаще всего, сразу понятно, какие пункты плана точно выполнимы. Главное - нужно внимательно посмотреть на те пункты, которые явно вызывают сомнения. И либо, немного подумать (например, устроить «мозговой штурм»), либо привлечь экспертов, либо, возможно, пойти другим, более простым, путем. Но, не следует ставить явно невыполнимые (недостижимые) цели и задачи!

Шаг 7. Построение дерева целей (и задач)

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

Шаг 8. Формирование перечня KPI с назначением ответственных сотрудников за конкретные KPI

Пример дерева целей и формирования перечня KPI на основе плана действий приведен в примере выше.

Шаг 9. Формирование мотивационных листов

Как реализовать такой проект

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

Далеко не всегда эффективно запускать крупный и сложный проект.

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

2. Небольшие пилотные проекты лучше делать в простейших и понятных средствах (например, в Word или в Excel). Для начала. Главное - это содержательная часть таких проектов, «положенная на бумагу». При реализации совсем небольшой задачи сделанные ошибки (а они будут!) можно быстро исправить.

3. Провести полный цикл моделирования - от решения какой-то небольшой задачи, до формирования KPI с условным «назначением» ответственных и формированием условных мотивационных листов.

Это оградит от ошибок и даст начальный опыт. Это и будет началом практики и началом создания системы KPI.

Пример. Допустим, в компании нет мотивационных листов (пока), нет системы KPI (пока), и ранее компания этот проект не реализовывала. Как смоделировать ситуацию? Выполнить пп. 1–3. KPI не назначать (!), и мотивационные листы «не вручать» (!). Просто поручить ответственному менеджеру то, что для него прописано. А потом сравнить то, что было спланировано, и что реально получилось.

Крайне важно стараться избегать «классических» ошибок. Для этого нужно выполнять следующее:

1. Обязательно формировать конечные цели проекта по созданию системы KPI. Цель - «выставить KPI» - «понятна». Но это все равно, что «повысить эффективность бизнеса», «обеспечить дальнейший рост компании» и т. д. Приведу пример спектра практических целей создания системы KPI:

Цель 1.1: проверка компетенций менеджеров и ключевых сотрудников с целью выявления «точек провалов» (некомпетентных сотрудников) и перспективных сотрудников (способных расти). Все-таки, ключевые показатели эффективности должны показывать (и показывают!) эффективность и неэффективность.
Цель 1.2: проверка эффективности сфер бизнеса компании (продажи, производство, пресейл, маркетинг и т. д.) с этой же целью.
Цель 1.3: проверка эффективности бизнес-процессов и коммуникаций в компании. Большинство крупных целей и задач реализуется силами различных подразделений. От слаженности их работы зависит рост компании. Не больше и не меньше! Это и есть та самая эффективность, о которой мы часто говорим.
Цель 1.4: проверка способностей менеджеров ставить достижимые цели (и задачи), их владение целеполаганием и т. д.
Цель 1.5: проверка способности компании достигать поставленные цели и задачи.
Цель 1.6: проверка достижения поставленных целей и задач, а также сравнение того, «куда стремились» и «куда пришли». Очень интересная цель! Допустим, стремились к одному, а рынок «поправил» движение компании, и компания пришла к лучшим результатам! Так редко бывает, конечно, но бывает. Это - хороший повод проанализировать прошлогоднее бизнес-планирование, с учетом выставленных KPI, и сделать выводы. Отличный результат!

2. План действий обязательно проверять на выполнимость, чтобы в нем не было недостижимых целей (и задач).

3. Обязательно назначать ответственных за конкретные KPI. Хотя бы моделировать это (для начала). Чтобы не получалось так, что за конкретные KPI реально никто не отвечает.

4. Проект по созданию системы KPI обязательно заканчивать мотивационными листами. Чтобы сформированные KPI не оказались «вне закона». Если это - пилотный проект, пусть это будет несколько KPI на период 2–3–4 месяца. Это - тоже правильно. И т. д.

Практический пример на основе методологии Balanced Scorecard (BSC)

Пример приведу на основе вышесказанного, с учетом упомянутой методологии и в виде последовательности практических действий. Допустим, вы начинаете с верхушки «Финансы» и вас беспокоит показатель «маржинальность». Понятно, что способов повысить маржинальность проектов очень много, поэтому нет смысла перечислять все эти способы. Нужно выбрать способы, присущие вашей компании, а также выявить причины недостаточной маржинальности.

Итак, очень условный план - только для примера:

KPI-1. Повысить маржинальность проектов не менее, чем на 7% за период времени не более, чем 6 месяцев.
Допустим, ключевые причины недостаточной маржинальности проектов следующие (условно):

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

Отсюда «вырастают» KPI следующего уровня для ряда служб компании. А именно (снова - условно):

KPI-1-1 (для Технической дирекции и руководителей проектов (РП)): выполнение проектов в сроки и в рамках бюджета проекта. Выполнен KPI по проекту - РП получил бонус. Нет - нужно разбираться, почему, а, возможно, и менять РП.
KPI-1-2 (для Блока маркетинга): вычислить отрасли, сегменты и ниши, более платежеспособные, чем те, с которыми сегодня работает компания. Подготовить презентацию и обосновать свои предложения. В течение <такого-то срока>.
KPI-1-3 (для Блока продаж): сформировать портфель проектов объемом не менее <такого-то>, в течение не менее <такого-то срока> (в плотном взаимодействии с маркетингом, чтобы не терять время). Чтобы была возможность выбора проектов для реализации.
KPI-1-4 (для Блока закупок) пока нет. Первоначально можно поставить задачу - проработать и дать предложения, как уменьшить стоимость закупаемого оборудования под проекты. И т. д.

Как, всё-таки, разработать реально работающую систему KPI в компании? Методик много, есть отдельные примеры, а вот найти алгоритм разработки реальной системы KPI, практически, невозможно. Надеюсь, читателю будет интересен предложенный алгоритм разработки и внедрения системы KPI "с нуля" (когда ещё ничего нет), заканчивая финальным результатом — работающей системой. Об этом в данной статье.

Введение

"Бог не на стороне больших батальонов, а на стороне лучших стрелков", — Вольтер.

В статье "Как разработать мотивационный лист для продавца? Стратегия и тактика", которая была опубликована 27 декабря 2016 в "Деловом мире", были показаны конкретные KPI для продавцов, взятые из реальной практики автора.

KPI — Key Performance Indicators — ключевые показатели эффективности деятельности подразделения, компании или предприятия. В русской аббревиатуре используется сокращение "КПЭ".

Начну с главного. Вопросы, которые обычно возникают, следующие:

Где взять эти самые KPI, и какие они должны быть? Будут ли эти KPI достижимы, и как это определить?
Какие KPI важны, а какие нет?
Как с помощью KPI увязать ключевые сферы деятельности компании, да так, чтобы KPI для маркетинга не противоречили KPI для продаж?
Какую методологию реализации проекта использовать? Допустим, выбрали методологию Balanced Scorecard (BSC) — Сбалансированную систему показателей. Что нужно делать далее?
С чего начать такой проект, и чем он должен закончиться? И т.д.

Вопросов масса. Ответов, как обычно, в разы меньше.

В статье "Как разработать "Штурвал руководителя" для управления крупной компанией", которая была опубликована 10 января 2017 в "Деловом мире", часть материала по этой теме есть, поскольку основа "Штурвала руководителя" — это система KPI.

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

Рассмотрим алгоритм создания системы KPI, когда стратегии развития бизнеса в компании нет. По шагам.

Шаг 1. Выбираем методологию реализации проекта создания системы KPI. Например, методологию Balanced Scorecard (BSC). Об этом я писал в статье "Как разработать "Штурвал руководителя", но повторюсь. Это — классические 4 "стены". См. Рис.1. Суть коротко:

Финансы . Финансы в компании обеспечиваются, всё-таки, продажами товаров и услуг.
Продажи . Чтобы с продажами было всё нормально, нужны технологии/продукты — те, которые востребованы рынком и те, которые можно рынку предлагать (продавать).
Технологии/продукты . Чтобы с технологиями/продуктами было всё нормально, нужны специалисты — люди, которые их создают.
Люди . Чтобы люди (способные к этому) создавали конкурентоспособные продукты, им нужно платить, их нужно обучать и развивать и т.д. Тогда они будут создавать продукты, продукты будут продаваться, и у компании с финансами будет всё в порядке. Далее компания сможет снова и снова инвестировать в людей для создания новых технологий/продуктов. Технические специалисты (производственный персонал) реализуют проекты, за которые заказчики, собственно, и платят деньги.

Шаг 2. Формируем структуру главных сфер деятельности компании. Например, для проектной компании — это:

"Стена" A:

Финансы . Простые параметры: доходы, расходы (оплата поставщикам, ЗП, аренда, ставки по овердрафтам, потери по курсовым разницам, налоги и т.д.), прибыль и т.д.

Набор более сложных макропараметров. Как-то: показатели ликвидности, структура капитала, рентабельность бизнеса, деловая активность и прочие в данной статье рассматривать не будем.

"Стена" B:

Продажи.
Маркетинг.

"Стена" C:

Ключевые направления развития (их состояние). Допустим, это — модернизация и расширение продуктовой линейки.
Пресейл .

"Стена" D:

Производство (реализация проектов).
HR (управление персоналом).

Комментарий: стоит отметить, что многие компании добавляют к классическим 4-м "стенам" свои "стены" (5-ую, 6-ую), являющиеся важнейшими в деятельности компании. Например, логистический блок.

Шаг 3. Определяем те сферы, которые мы хотим усилить. Или сферы, по которым у нас есть явные "точки провалов". "Точки провалов" — это не полные провалы в бизнесе. Это — то, что не работает, или работает не очень хорошо. Задача понятна — ликвидировать "точки провалов". Такие "точки провалов" есть в каждой компании.

Пример задачи. Допустим, у нас, в целом, всё более-менее нормально, за исключением того, что отраслевой сегмент 1 перестал приносить прибыль, но мы видим, что перспективен отраслевой сегмент 2 (или новая перспективная ниша), с которым нужно срочно начать работать.

Пример плана действий

Подготовить/скорректировать продуктовую линейку для нового Отраслевого сегмента 2 (для краткости — новая отрасль — "НО"). Это — "стена" С.
Найти профессионального директора по продажам для "НО". Это — "стена" B и D, т.к. это — задача для директора по продажам компании и для HR:
Разработать профиль клиента "НО". Это — "стена" B.
Разработать профиль директора "НО". Это — "стена" B.
Разработать основные параметры мотивации директора "НО". Это — "стена" B.
Разработать мотивационный лист директора "НО" и согласовать его. Это — "стена" D.
Осуществить поиск/хантинг директора "НО". Это — "стена" D.
Сформировать новый отраслевой департамент — для краткости — "НОД" — (бюджет, центры ответственности, штатное расписание и т.д.). Это — "стена" B.
- Поставить задачи директору "НОД". Это — стена "B".
- Разработать основные параметры мотивации продавцов "НОД". Это — "стена" B.
- Разработать мотивационные листы продавцов "НОД" и согласовать их. Это — стена "D".
- Перевести часть продавцов, часть принять на работу в "НОД", часть, возможно, уволить. Это — "стена" B и D.
Поставить задачи пресейл для продвижения решений компании в "НО". Это — "стена" D.
Поставить задачи маркетингу для продвижения решений компании в "НО". Это — "стена" B.
И т.д.

Пример дерева целей и KPI

"Стена" С:

KPI (технического директора):

Подготовить/скорректировать продуктовую линейку для "НО".
Поставить задачи пресейл для продвижения решений компании в "НО".

"Стена" B:

KPI (директора по продажам компании):

Разработать профиль клиента "НО".
Разработать профиль директора "НО".
Разработать основные параметры мотивации директора "НО".
Сформировать "НОД" (бюджет, центры ответственности, штатное расписание и т.д.).
Поставить задачи директору "НОД" (после того, как HR найдёт директора).
Поставить задачи маркетингу для продвижения решений компании в "НО".

KPI (Директора "НОД"):

Разработать основные параметры мотивации продавцов "НОД". Согласовать их с директором по продажам компании и передать в HR.
Отсмотреть продавцов (существующих и новых), принять решения.

"Стена" D:

KPI (директора по HR):

Разработать мотивационный лист директора "НО" и согласовать его с Директором по продажам компании.
Осуществить поиск/хантинг директора "НО" (найти профессионального директора по продажам).
Разработать мотивационные листы продавцов "НОД" и согласовать их с директором "НОД".
Осуществить поиск/хантинг продавцов в "НОД".
Перевести часть продавцов, часть принять на работу в "НОД", часть, возможно, уволить.

Комментарий: понятно, что есть задачи и для "стены" A — спланировать новые расходы в бюджете компании и т.д.

Департамент должен будет возглавить профессиональный в этой отрасли директор по продажам.
Мы спланировали все необходимые действия, связанные с закрытием, либо уменьшением в размерах Отраслевого направления 1, если его пока закрыть нельзя.
Техническому департаменту, маркетингу, HR и пресейл поставлены соответствующие задачи, которые должны выполнить свою часть работы, согласно их профилю, и поддержать новое направление "по всем фронтам".

Уважаемый читатель, наверняка, подумает: "Легко сказать: взять на работу профессионального директора по продажам нового отраслевого сегмента!" Сложно! Как делал автор? Я формировал несколько списков для HR.

Cписок №1. Крупные и средние компании, в которых есть смысл искать директора или заместителя директора аналогичного направления. Не получается, тогда:
Список №2. Меньшие по размеру компании, в которых есть смысл искать директора. Человек будет немного на вырост, но он будет внутри более отстроенной компании. И для него это будет карьерный рост. Не получается, тогда:
Список №1. Искать в крупных и средних компаниях сильного продавца, а не менеджера. Также на вырост. Не получается, тогда:
Список №1. Искать близкого по отраслевому признаку директора, с учётом его способностей освоить новую отрасль.
И т.д. Были и другие варианты.

"Для человека, который не знает, к какой гавани он направляется, ни один ветер не будет попутным", — Луций Анней Сенека Младший.

Детали KPI можно формировать, используя, например, широко известную методологию постановки целей S.M.A.R.T. Поэтому…

Шаг 4. Изучить методологию целеполагания, которая будет использоваться при постановке целей:

Например, методологию постановки целей S.M.A.R.T.

Идём дальше. Определили сферы, которые мы хотим усилить. Или сферы, по которым у нас точно есть "точки провалов". Что дальше? Далее мы разрабатываем план действий (см. пример выше), который позволит нам усилить эти сферы и/или ликвидировать "точки провалов". Без целостного плана действий, построить систему KPI, которая объединит работу различных служб компании, не реально. Во всяком случае, довольно сложно.

Шаг 5. Разработка плана действий:

На Шаге 3 я показал пример плана действий, не самого тривиального, но который вполне можно реализовать, и такие планы действий довольно часто компаниями реализуются. Что важно? — содержательный подход к решению задач!

Шаг 6. Проверка плана действий на выполнимость:

Опыт показывает, что чаще всего, сразу понятно, какие пункты плана точно выполнимы. Главное — нужно внимательно посмотреть на те пункты, которые явно вызывают сомнения. И либо, немного подумать (например, устроить "мозговой штурм"), либо привлечь экспертов, либо, возможно, пойти другим, более простым, путём. Но, не следует ставить явно невыполнимые (недостижимые) цели и задачи!

Шаг 7. Построение дерева целей (и задач):

Итак, план действий есть. Есть цели и задачи. Остаётся построить дерево целей (и задач) и назначить ответственных. Если появились новые Центры ответственности — ну, не было ранее этих функций — значит, нужно согласно новым Центрам ответственности модифицировать организационную структуру компании. Так, в общем-то, компании и растут.

Шаг 8. Формирование перечня KPI с назначением ответственных сотрудников за конкретные KPI:

Пример дерева целей и формирования перечня KPI на основе плана действий приведён в примере выше.

Шаг 9. Формирование мотивационных листов:

Вот пока в мотивационных листах не появятся аналогичные (приведённым выше) качественные цели (а в примере выше нет ни одной финансовой цели!), система KPI работать не будет! Она останется "на бумаге". То, что приведено в примере выше — это то, что нужно срочно делать! Ровно для того, чтобы не "наработать" кучу лишних затрат, и что ещё хуже — убытков, и ровно для того, чтобы как можно быстрее обеспечить дальнейший рост компании. Разумеется, финансовый!

"Невозможно решить проблему на том же уровне, на котором она возникла. Нужно стать выше этой проблемы, поднявшись на следующий уровень",-Альберт Эйнштейн.

Как реализовать такой проект?

Я очень часто слышу "пробовали — не получается!". Довольно много причин, по которым такие проекты не доходят до стадии эксплуатации и финального результата.

Мы часто забываем, что человек — не машина. Поэтому на основании собственного опыта я бы рекомендовал следующее:

Начинать с небольших пилотных проектов, ограниченных по сферам деятельности компании и спектру задач. Цель проста — быстро наработать навык. Совсем не обязательно сразу вводить наработки в действие. Можно моделировать ситуацию (см. п.3).

Далеко не всегда эффективно запускать крупный и сложный проект.

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

Небольшие пилотные проекты лучше делать в простейших и понятных средствах (например, в Word или в Excel). Для начала. Главное, это — содержательна часть таких проектов, "положенная на бумагу". При реализации совсем небольшой задачи сделанные ошибки (а они будут!) можно быстро исправить.
Провести полный цикл моделирования — от решения какой-то небольшой задачи, до формирования KPI с условным "назначением" ответственных и формированием условных мотивационных листов.

Это оградит от ошибок и даст начальный опыт. Это и будет началом практики и началом создания системы KPI.

Пример. Допустим, в компании нет мотивационных листов (пока), нет системы KPI (пока), и ранее компания этот проект не реализовывала. Как смоделировать ситуацию? Выполнить пп.1-3. KPI не назначать (!) , и мотивационные листы "не вручать" (!) . Просто поручить ответственному менеджеру то, что для него прописано. А потом сравнить то, что было спланировано, и что реально получилось.

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

Обязательно формировать конечные цели проекта по созданию системы KPI. Цель — "выставить KPI" — "понятна". Но это всё равно, что "повысить эффективность бизнеса", "обеспечить дальнейший рост компании" и т.д.

Приведу пример спектра практических целей создания системы KPI:

Цель 1.1: проверка компетенций менеджеров и ключевых сотрудников с целью выявления "точек провалов" (некомпетентных сотрудников) и перспективных сотрудников (способных расти). Всё-таки, ключевые показатели эффективности должны показывать (и показывают!) эффективность и неэффективность.
Цель 1.2: проверка эффективности сфер бизнеса компании (продажи, производство, пресейл, маркетинг и т.д.) с этой же целью.
Цель 1.3: проверка эффективности бизнес-процессов и коммуникаций в компании. Большинство крупных целей и задач реализуется силами различных подразделений. От слаженности их работы зависит рост компании. Не больше и не меньше! Это и есть та самая эффективность, о которой мы часто говорим.
Цель 1.4: проверка способностей менеджеров ставить достижимые цели (и задачи), их владение целеполаганием и т.д.
Цель 1.5: проверка способности компании достигать поставленные цели и задачи.
Цель 1.6: проверка достижения поставленных целей и задач, а также сравнение того, "куда стремились" и "куда пришли". Очень интересная цель! Допустим, стремились к одному, а рынок "поправил" движение компании, и компания пришла к лучшим результатам! Так редко бывает, конечно, но бывает. Это — хороший повод проанализировать прошлогоднее бизнес-планирование, с учётом выставленных KPI, и сделать выводы. Отличный результат!
План действий обязательно проверять на выполнимость. Чтобы в нём не было недостижимых целей (и задач).
Обязательно назначать ответственных за конкретные KPI. Хотя бы моделировать это (для начала). Чтобы не получалось так, что за конкретные KPI реально никто не отвечает.

"То, что является делом всех, не является ничьим делом", — Изаак Уолтон.

Проект по созданию системы KPI обязательно заканчивать мотивационными листами. Чтобы сформированные KPI не оказались "вне закона". Если это — пилотный проект, пусть это будет несколько KPI на период 2-3-4 месяца. Это — тоже правильно.
И т.д.

Практический пример на основе методологии Balanced Scorecard (BSC)

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

Итак, очень условный план — только для примера.

KPI-1. Повысить маржинальность проектов не менее, чем на 7% за период времени не более, чем 6 месяцев.

Допустим, ключевые причины недостаточной маржинальности проектов следующие (условно):

Высокие затраты по проектам, в связи с невыполнением проектов в сроки.
Большинство проектов сами по себе не имеют достаточной маржинальности. Далее — мы часто "вылетаем" из сроков и бюджета, и маржинальность становится ещё меньше.
Нет возможности выбирать более прибыльные проекты из имеющего портфеля проектов. Проектов и так мало, а портфеля потенциальных проектов почти нет.
Высокая стоимость закупок оборудования под проекты, что не добавляет маржинальности.
Нет уникальных (почти уникальных или высококачественных) услуг, за счёт которых компания может "брать за проекты" дополнительные деньги.
И т.д.

Отсюда "вырастают" KPI следующего уровня для ряда служб компании. А именно (снова — условно):

KPI-1-1 (для Технической дирекции и руководителей проектов (РП)): выполнение проектов в сроки и в рамках бюджета проекта. Выполнен KPI по проекту — РП получил бонус. Нет — нужно разбираться, почему, а, возможно, и менять РП.
KPI-1-2 (для Блока маркетинга): вычислить отрасли, сегменты и ниши, более платёжеспособные, чем те, с которыми сегодня работает компания. Подготовить презентацию и обосновать свои предложения. В течение <такого-то срока>.
KPI-1-3 (для Блока продаж): сформировать портфель проектов объёмом не менее <такого-то>, в течение не менее <такого-то срока> (в плотном взаимодействии с маркетингом, чтобы не терять время). Чтобы была возможность выбора проектов для реализации.
KPI-1-4 (для Блока закупок) пока нет. Первоначально можно поставить задачу — проработать и дать предложения, как уменьшить стоимость закупаемого оборудования под проекты.
И т.д.

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

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

Проекты, над которыми я работаю, чаще всего связаны с разработкой заказного или инвестиционного программного обеспечения. Также мне приходилось работать с встроенным ПО и программами, ориентированными на выпуск «хитов» (что, с лёгкой руки Джоэля Спольски, я называю далее игровым ПО, хотя на самом деле некоторые игровые проекты ближе к инвестиционным).

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

В отличие от заказного ПО, работа над инвестиционным программным обеспечением ведётся самим исполнителем на деньги внутреннего или внешнего инвестора. Как правило, права на код системы остаётся у исполнителя, что стимулирует непрерывную работу по улучшению своего продукта и последовательный выпуск версий с более развитой функциональностью.

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

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

Нашими заказчиками являются органы власти, крупные государственные и коммерческие организации и, конечно, мы сами. Поэтому в смысле заказного ПО в нашем процессе часто присутствует некоторая разница между процессами разработки продуктов для внутреннего и для внешнего заказчиков. Некоторые нюансы я укажу в этой статье. Уровень формализации отношений с заказчиком у нас варьируется от проекта к проекту очень широко. В целом, чем больше бюджет проекта, тем выше формальность. Государственный заказчик или крупные коммерческие предприятия (особенно с государственным участием) обычно имеют законодательные ограничения на формирование, размещение заказа и приёмку результатов работ. Ещё одним ограничением крупных организаций является тот факт, что их персонал, являющийся источником требований и основным пользователем наших систем, имеет очень ограниченную доступность для исполнителей, хотя бы вследствие своей занятости. Однако для небольших организаций уровень формализации падает и иногда уходит в противоположную крайность, где возникает недостаточный уровень ответственности заказчика в рамках проекта.

Другая сторона наших заказных проектов – высокие требования к функциональности. Это и высокая нагрузка на все системы, и большая географическая распределённость, и высокие требования к точности вычислений при очень ограниченных временных рамках. Часто в наших проектах появляются элементы исследовательской работы и творческого поиска, направленного на решение нетривиальных проектных задач. Иногда нам приходится комбинировать в рамках одного процесса разработки разные методологии, например, вставляя в общий процесс, близкий к RUP, один или несколько этапов почти чистого scrum, порождая что-то вроде проекта в проекте. Это позволяет нам сохранять невысокий уровень вовлеченности пользователей, связанный с природой проекта, с гибкостью разработки в условиях высокой неопределённости требований. В этом плане для меня важен именно подготовительный этап, во время которого можно выбрать необходимую методологию и выстроить оптимальный процесс разработки. Один из примеров применения гибкой методологии я описал в статье «Применение agile при разработке проекта для государственного заказчика» .

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

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

Важно понимать, что переход процесса от одного этапа к другому не имеет чёткой границы. Как правило, работы следующего этапа начинаются по мере выполнения 80-90% работ по предыдущему этапу. Особенно это касается разработки требований, когда в ряде случаев снятие неопределённости происходит лишь к концу проекта. Безусловно, наличие такой неопределённости в проекте является существенным риском и должно находиться под постоянным контролем.

Процесс разработки заказного ПО

Обзор процесса разработки начнём с наиболее общего случая – разработки заказного программного обеспечения. Схема процесса приведена на рисунке 1.

Рисунок 1. Процесс разработки заказного программного обеспечения.

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

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

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

Иногда уточнение требований приводит к пересмотру концепции проекта. Если после уточнения всех требований не удаётся найти приемлемого технического решения, проект приходится сворачивать либо откладывать на некоторое время в ожидании более приемлемых обстоятельств.

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

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

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

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

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

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

Осталось отметить ещё два этапа процесса разработки. Бывает, что обстоятельства не позволяют продолжать реализацию проекта, но результаты проделанной работы показывают, что у проекта может быть будущее. Закрывать такой проект преждевременно. Поэтому вместо полной остановки работ исполнитель может временно приостановить деятельность по проекту, зафиксировав достигнутые результаты. Как только обстоятельства позволят, проект можно буде возобновить, расконсервировав инфраструктуру, вернув в проект разработчиков и восстановив состояние проекта. Важно, однако, возобновлять работу с того этапа, на котором проект был прерван, повторно проведя ревизию достигнутых результатов.

Процесс разработки инвестиционного ПО

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

Рисунок 2. Процесс разработки инвестиционного программного обеспечения.

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

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

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

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

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

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

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

Особое внимание нужно уделить стендам, на которых проводится тестирование: на них должны быть развёрнуты все версии продукта, которые были выпущены ранее (по меньшей мере, те версии, которые сопровождаются), и все версии, разработка которых ведётся в настоящий момент.

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

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

Процесс разработки встроенного ПО

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

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

Таким образом, при разработке встроенного ПО возникает сразу несколько важных ограничений.

Во-первых, поставка выполняется в рамках только одного этапа: никто не будет встраивать в устройства наполовину работающую программу.

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

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

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

Процесс разработки встроенного ПО показан на рисунке 3.

Рисунок 3. Процесс разработки встроенного программного обеспечения.

Процесс разработки игр

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

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

Указанные факторы сказываются на процессе разработки игрового ПО. Процесс представлен на рисунке 4.

Рисунок 4. Процесс разработки игрового программного обеспечения.

Нужно отметить следующие особенности процесса разработки игрового ПО.

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

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

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

Для игрового ПО нет этапов опытной эксплуатации и вывода из эксплуатации. Игры сразу поступают в продажу, а после использования просто удаляются пользователем по мере утраты интереса к ним.

Заключение

В рамках статьи я попытался сделать обзор «верхнего уровня» процесса разработки прикладного программного обеспечения. Каждый этап процесса, безусловно, нуждается в отдельном обсуждении с обязательным учётом особенностей разрабатываемых программных средств.

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