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

Критерии выбора

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

Механизмы разработки ПО

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

Принципы организации разработки ПО

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

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

Цель организации разработки ПО

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

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

Для получения подробной информации о разработке программного обеспечения обратитесь к нашим менеджерам.

Данная аттестационная работа направлена на описание и оптимизацию бизнес-процессов компании-разработчика программного обеспечения (далее – ПО).

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

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

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

Стратегический анализ деятельности компании;

Описание текущего положения и штатной структуры компании;

Описание существующих бизнес-процессов;

Анализ и оптимизация бизнес-процессов, выработка рекомендаций по их изменению, регламентирование деятельности;

Оптимизация штатной структуры компании;

Анализ проблем и выработка решений по управленческим и кадровым проблемам компании;

Создание образцов типовых документов;

Определение перспективных направлений автоматизации деятельности.

1.Стратегический анализ деятельности компании

1.1 Обоснование выбора организации

ВкачествеисследуемойорганизациивыбранаООО«Кварта».

Основными направлениями деятельности компании являются:

Разработка программного обеспечения (ПО);

Внедрение и сопровождение программного обеспечения;

Поставка аппаратного обеспечения;

Техническая поддержка.

При этом разработка ПО ведется в двух направлениях – ПО сферы бухгалтерского учета разрабатывается на одной платформе, а ПО остальных направлений – на другой (т.н. ИИС).

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

Организационно-штатная структура компании еще больше усугубляет вышеуказанные проблемы.

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

Описание организации приведено в Таблице 1.

Таблица 1.Описание организации как объекта управления

Параметр описания	Характеристика
Название, местонахождение	ООО «Кварта», г. Москва
Назначение	Оказание услуг автоматизации для федеральных и территориальных органов государственной власти, бюджетных учреждений, а также для малых и средних предприятий (разработчик и поставщик услуг по внедрению и сопровождению автоматизированных информационных систем (АИС), системная интеграция)
Отраслевая принадлежность	Отрасли третичного цикла Частная фирма Информационные технологии
Правовая форма и вид собственности	Коммерческое предприятие, общество с ограниченной ответственностью, частное
Историческая справка	Образовалась в 1993 году. Первый заказчик Управление делами Президента РФ Начало создания финансово-бухгалтерской системы, организация ЛВС. Постепенно в компании образовался ряд направлений деятельности, которые впоследствии переросли в отдельные компании («Кварта-технологии», «Кварта-сети», «Кварта-консалтинг», Кадровое агентство «Кварта», «Сенсорные системы» и др.). Непосредственно сама компания занялась разработкой интегрированных информационных систем управления предприятием (ИИС), а также комплексной автоматизацией организаций и предприятий. Основным направлением деятельности были выбраны федеральные органы законодательной и исполнительной власти РФ. На данный момент заказчиками услуг компании являются Аппарат Правительства, Государственная Дума, Совет Федерации, Счётная палата, УД Президента РФ и большая часть Министерств, федеральных служб и агентств, включая подведомственные организации и загранучреждения, а также коммерческие организации различных форм собственности. Список предоставляемых услуг постоянно растёт, появляются новые продукты. В планах компании расширить влияние в секторе муниципальных образований и продвижение в регионы. Также компания постепенно расширяет деятельность в секторе коммерческих предприятий.
Организационная структура	См. ниже (Модель «Цепочки ценностей»)
Структура управления	В данный момент компания использует вертикальную систему управления от генерального директора к руководителям структурных подразделений (департаментов), часть из которых выполняет функции заместителей, далее к начальникам отделов и групп. Подразделения поделены по функциональному признаку. В последнее время в связи с большим количеством разнородных проектов, требующих специалистов разных направлений, постепенно вводится практика назначения руководителей проектов (как правило руководители отделов) и планируется серьёзная структурная реорганизация.
Параметр описания	Характеристика
Ресурсы	Основной ресурс – сотрудники. Поощрение инициативных сотрудников, дружеская атмосфера в коллективе. Большое внимание уделяется обучению. Репутация в секторе разработки ПО для федеральных органов, рекомендации клиентов. Накопленный опыт, знание до тонкостей специфики работы в данном секторе. Многолетний опыт работы и большое количество завершенных проектов, что позволяет участвовать и выигрывать конкурсы. Технические ресурсы: помещения, коммуникации (телефония, широкополосный доступ в Интернет), вычислительная техника, транспорт.
Культура	Высокая мотивация сотрудников, преданность фирме, устоявшийся коллектив, дружественные отношения в коллективе, знание целей и перспектив.
Ключевые факторы внешней среды	Законодательство: Изменчивое законодательство, постоянные нововведения, часто не подкреплённые методическими рекомендациями, ограниченное время на реализацию изменений. Заказчики: Специфика данного рынка (федеральные органы власти) в том, что на процесс разработки / внедрения дается очень мало времени. Часто через несколько дней после подписания контракта система должна полностью функционировать и быть наполненной информацией. Многое делается по принципу «надо вчера». Как правило, отсутствие единых стандартов, руководство заказчиков часто дает противоречивые указания, диктует собственные условия, часто расходящиеся с реальностью. Ограниченное, часто запаздывающее финансирование. Как правило, платформы для приложений определены заранее, поэтому необходим большой арсенал версий под разные платформы. Конкуренция: Конкуренция высокая, как правило, выигрывает не лучший продукт или предложение, а лучшая протекция со стороны заказчика. Каждый руководитель имеет свои устоявшиеся связи и поставщиков, поэтому часто борьба идет не за конкурентные преимущества, а за протекцию. Новые игроки как правило отсутствуют, конкурируют как правило компании с устоявшейся клиентской базой, по причине того, что в данном сегменте требуется большой опыт и специфическое отношение к заказчикам. Технологии: сильная зависимость от тенденций развития технологий, необходимость следовать за тенденциями рынка, плюс необходимость поддержки большинства актуальных технологий.
Руководство	Генеральный директор, он же собственник: оперативное управление деятельностью компании, консолидированная стратегия, участие в переговорах с ключевыми заказчиками. Также в данный момент есть 3 заместителя, они же являются руководителями основных департаментов компании. Каждый ведет свой круг вопросов в рамках департамента, выработку стратегии своего направления, переговоры и пр. и осуществляет координацию с другими подразделениями.
Параметр описания	Характеристика
Модель «Цепочки ценностей»	Процессы основной деятельности: Разработка: выпуск качественных и функциональных продуктов с максимальным функционалом, необходимым заказчику. Следование новым технологиям и поддержка большого количества платформ. Интеграция: полный комплекс услуг, начиная с этапа сбора информации и проектирования, до сдачи в эксплуатации функционирующих в соответствии с требованиями заказчика программно-аппаратных комплексов Сопровождение: ключевой особенностью является постоянная поддержка систем у заказчика. Компания никогда не оставляет заказчиков один на один с информационной системой. Как правило при необходимости у заказчика присутствуют сотрудники компании, часто выделяются постоянные представители. Это позволяет существенно улучшить быстроту и качество обслуживания. Поставки: поставка любых аппаратно-программных продуктов различных производителей, настройка, адаптация, ввод в эксплуатацию. Широкие партнёрские отношения с производителями. Предоставление услуг: также компания специализируется на предоставлении услуг по обслуживанию компаний, с уже работающей аппаратно-программной инфраструктурой, осуществляет, разрабатывает заказные продукты. Поиск заказчиков: мониторинг проводимых конкурсов, выбор оптимальных предложений, подготовка конкурсной документации, участие в конкурсах, итоговая документация Процессы вспомогательной деятельности: Разработка систем для внутреннего пользования Поддержка программно-аппаратной части компании Управление персоналом (мотивация, обучение и пр.) Снабжение Внутренний финансово-бухгалтерский учёт Технологические исследования Делопроизводство

1.2 Организационно-штатная структура

Существующая штатная структура организации приведена на Рисунке 1.

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

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

Кадровая служба не существует в виде отдельного подразделения.

Рисунок 1. Существующая штатная структура.

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

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

1.3 Основные проблемы управления

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

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

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

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

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

Отсутствие планирования. Часто приводит к авральному выполнению проектов и нехватке сотрудников.

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

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

1.4 Постановка стратегических целей

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

Миссия

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

Стратегический профиль

Текущую стратегию я бы сформулировал следующим образом:

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

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

Видение (стратегическое намерение)

1. Какой мы хотим видеть свою организацию в будущем?

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

2. Что из себя представляет наш бизнес сейчас и каким он будет в будущем?

В последнее время бизнес начал быстро развиваться. Количество заказов растет. Но четкого представления о планах и объемах работ нет практически не у кого. 80% времени персонал работает в авральном режиме. Рост внутри компании скорее носит экстенсивный характер (рост объема заказов – существенный рост штата), что не всегда оправдано. Приход новых клиентов часто происходит по принципу - мы слышали от тех-то, что есть такая компания, что у вас хорошие продукты и вас нашли. Маркетинговая политика отсутствует практически полностью.

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

3. Кто является потребителями нашей продукции (услуг) и на какую группу покупателей организация будет ориентироваться в будущем?

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

4. Какими способами мы собираемся увеличивать ценность нашей продукции для потребителей?

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

Стратегические цели

1. Сроки стратегического планирования.

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

2. Генеральная цель.

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

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

Завершить реорганизацию структуры (создание новых структурных подразделений и распределение функций между ними)

Выделение в отдельную структуру аналитиков и проектировщиков.

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

Повысить профессиональный уровень сотрудников

Создать систему обучения вновь принятых сотрудников

Внедрить систему аттестации сотрудников

Организовать процесс повышения профессиональной подготовки кадров

Проведение тематических семинаров

Формализовать процессы.

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

Перейти к грамотной, качественной и формализованной постановке задач

Организовать процесс документирования производимых работ

Стандартизировать процессы планирования и отчётности

1.5 Анализ и выбор стратегии

Результаты SWOT-анализа приведены в таблице 2 и таблице 3.

Таблица 2.Анализ факторов, воздействующих на достижение стратегических целей

Факторы	Шифр	Содержание	Оценка
Сильные стороны организации	S1		7
	S2		6
	S3		8
	S4		9
Итого	30
Слабые стороны организации	W1		7
	W2	Низкий уровень менеджмента организации, структура, не отвечающая текущим требованиям	8
	W3		6
Итого	21
Возможности окружающей среды	O1		7
	O2		9
	O3	Увеличение финансирования по программе «Электронная Россия», рост ИТ-рынка в целом	8
Итого	24
Угрозы окружающей среды	T1		4
	T2		6
	T3		8
Итого	18

Таблица 3.Итоговая стратегическая матрица

Сильные стороны организации				Слабые стороны организации
S1	S2	S3	S4	W1	W2	W3
Возможности	S3-O2 Увеличение объемов поставок решений заказчикам S4-O3 Рост количества клиентов S1-O3 Расширение линейки продуктов S3-O1 Практически монополия по ряду поставляемых задач S2-O2 Возможность работы в кредит S4-O1 Возможность получения дополнительных разрешений S2-O1 Возможность выпускать продукты с соотв. с самыми современными технологиями				W1-O3 Использовать средства для модернизации линейки продуктов, вкладывать в новые технологии W3-O2 Возможность планирования работ заранее, оптимальное использование ресурсов W1-O1 Использование партнёрской поддержки для скорейшего освоения последних технологий W2-O3 Реорганизация системы управления, поиск профессиональных кадров
O1
O2
O3
Угрозы	S1-T1 Возможность текучки кадров. Повышать заинтересованность, постоянный мониторинг. S2-T1 Не терять финансовую независимость, что позволит существовать в кризисные моменты достаточно продолжительное время, предоставлять возможность работы в кредит S3-T3 Постоянно отслеживать изменение технологий, заниматься перспективными разработками. S2-T2 выпускать новый продукт раньше, чем конкуренты				W1-T3(Т1) Как можно скорее перейти на более совершенную платформу W3-T1(Т2) Отслеживать состояние рынка, тщательно планировать деятельность W2-T2 Привести структуру в соответствие с возникшей необходимостью, повышать квалификацию менеджеров
T1
T2
T3
T4

Граф типовых стратегий организации приведен на рисунке 2.

Рисунок 2. Граф типовых стратегий

Выбор и обоснование стратегии

В таблице 4 приведен выбор и оценка факторов, задействованных в трёх базовых стратегиях.

Таблица 4.Выбор и оценка факторов, задействованных в трёх базовых стратегиях

Факторы	Оценка	Реструктуризация (лидерство по издержкам)		Дифференциация		Комбинированная стратегия
		Удельный вес фактора		Удельный вес фактора	Средне-взвешенная оценка фактора	Удельный вес фактора	Средне-взвешенная оценка фактора
S1	7	0,1	0,7	0,1	0,7	0,1	0,7
S2	6	0,15	0,9	0,2	1,2	0,18	1,08
S3	8	0,1	0,8	0,25	2	0,17	1,36
S4	9	0,15	1,35	0,25	2,25	0,2	1,8
W1	7	0,15	1,05	0,05	0,35	0,1	0,7
W2	8	0,15	1,3	0,1	0,8	0,12	0,96
W3	6	0,2	1,2	0,05	0,3	0,13	0,78
Итого	1	7,3	1	7,6	1	7,38
O1	7	0,15	1,05	0,2	1,4	0,17	1,19
O2	9	0,15	1,35	0,2	1,8	0,17	1,53
O3	8	0,15	1,2	0,25	2	0,2	1,6
T1	4	0,2	0,8	0,05	0,2	0,13	0,52
17T2	6	0,2	1,2	0,15	0,9	0,18	1,08
T3	8	0,15	1,2	0,15	1,2	0,15	1,2
Итого	1	6,8	1	7,5	1	7,12

По сумме оценок:

По сумме оценок наилучшей стратегией является стратегия дифференциации.

По реальности задействованных факторов:

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

Выбранная стратегия

Возможные действия в рамках реализации стратегии:

Совершенствование и расширение линейки продуктов

Повышение профессионального уровня сотрудников

Повышение значимости планирования.

Агрессивная маркетинговая политика расширение партнёрских отношений.

Возможные последствия реализации выбранной стратегии

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

К недостаткам можно отнести следующее:

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

Надо очень серьёзно прорабатывать данные вопросы во избежание негативного влияния.

Реализация системы планов. Эффективность изменений

Определение необходимых изменений приводится в таблице 5.

Таблица 5.Определение необходимых изменений

Шифр	Наименование	Вес	7S	Реакция
S1	Сплоченный, высокопрофессиональный коллектив.	0,8	Shared Values	Держать уровень оплаты труда на рыночном уровне, предоставлять бонусы и гарантии. Разработать программы мотивации и повышения квалификации персонала, ввести аттестацию.
S2	Хорошая технологическая база, финансовая независимость	0,7	Skills	Технологическая база должна соответствовать современному уровню, обновлять при необходимости, использовать имеющиеся возможности для привлечения перспективных клиентов (кредит…)
S3	Актуальные инновационные разработки, учитывающие специфику рынка	1,4	Skills	Поддерживать высокое качество продуктов, уделять больше внимания заказчикам. Донести до потенциальных заказчиков преимущества (маркетинговая программа), всегда быть в курсе последних изменений, выводить на рынок продукты раньше конкурентов.
S4	Отличная репутация и долгов время пребывания на рынке	1,7
W1	Две линейки однородных продуктов, одна из которых использует устаревшую платформу	0,7		Отказаться от разработки двух линеек продуктов, перевести их на единую интегрированную платформу, сделать продукт современным и качественным. Постоянно проводить инновационные исследования и создать непрерывный цикл периодических обновлений.
W2	Низкий уровень менеджмента организации, структура не отвечающая текущим требований	1,2		Реорганизация структуры компании, формализация процессов, ввод в эксплуатацию внутренней информационной системы и рамках неё систем планирования, отчётности и пр. Обучение руководящего состава, привлечение новых кадров.
W3	Отсутствие маркетинговой политики и долгосрочного планирования	1		Разработка маркетинговой стратегии. Выработка стратегических планов и направлений развития компании на основе имеющихся знаний и возможностей.
O1	Наличие лицензий и разрешений соответствующих органов, партнёрство с поставщиками СУБД и системного ПО	1,4	Skills	Развивать партнёрские отношения с поставщиками. Лицензировать деятельность и обеспечивать наличие разрешений во всех требуемых направлениях.
O2	Наличие действующих контрактов, необходимых связей, владение необходимой информацией	1,7		Обеспечивать качественное выполнение контрактов с целью их продления, расширения услуг и повышения репутации. Расширять связи с целью своевременного получения информации.
O3	Увеличение финансирования по программе «Электронная Россия», рост ИТ рынка в целом	1,6		Развивать маркетинговую политику, активно участвовать в конкурсах, предлагать качественные, функциональные, опережающие конкурентов продукты
T1	Снижение финансирования госсектора, финансовые потрясения	1,2		Иметь резервные фонды и возможность предоставления услуг в кредит, широкий спектр продуктов и услуг. Поддерживать коллективный дух и корпоративные ценности.
T2	Риск активизации текущих игроков рынка	0,7	Strategy	Вести активный мониторинг рынка. Владеть информацией. Иметь широкую продуктовую линейку с сильными конкурентными преимуществами.
T3	Зависимость от тенденций рынка в области платформ разработки	1		Активно сотрудничать с поставщиками, развивать партнёрские отношения. Повышать профессиональный уровень сотрудников, заниматься инновационными разработками.

Разработка мероприятий, программ и планов

Планирование

1. Создание плана реорганизации.

2. Планирование рабочего времени сотрудников.

3. Создание маркетингового плана

4. Создание плана обучения и переподготовки персонала

Организация

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

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

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

3. Написание детальных должностных инструкций

4. Детальное распределение полномочий и распределение проектов. Назначение ответственного за результат.

Мотивация

В таблице 6 приводятся показатели качества трудовой жизни.

Таблица 6.Показатели качества трудовой жизни

Показатель	Положение в данный момент
Справедливая заработная плата
Рыночная оплата труда	Присутствует (но ближе к нижней планке). Есть институт премирования по итогам года и завешенных проектов, но носит субъективный характер.
Обоснованная дифференциация оплаты труда	В зависимости от должности
Индивидуальная ответственность за результаты общего труда	Присутствует, начиная со среднего уровня, но никоим образом не отражается в оплате труда
Доп. вознаграждение за длительный стаж работы в компании	Фактически отсутствует
Программа дополнительных выплат
Выплата работнику и его семье в случае болезни	да, по базовой ставке оплаты труда
Оплачиваемое время отпуска в связи с праздниками и отпусками	да, в соответствии с КЗОТ
Оплачиваемые отпуска для дополнительного образования	Оплачиваются в случае, если обучение происходит по направлению фирмы
Условия безопасности труда и охраны здоровья	на уровне «здравого смысла»: все используемое оборудование в работе соответствует международным стандартам безопасности, офисные площади планируются из рекомендованных санитарных норм.
Гарантия занятости
Обеспечение непрерывности трудового стажа	да, в соответствии с КЗОТ
Уверенность работников в своем будущем	Да, стабильная компания, 15 лет на рыке.
Развитие способностей работников	Обучение происходит стихийно или по необходимости.
Социальная интеграция
Социально-психологический микроклимат в организации	Нейтральный. Много как позитивных, так и негативных моментов. Присутствует некая обособленность структурных единиц.
Отношение руководства и подчиненных	Между руководителями подразделений и подчиненными- ближе к демократическому.
Участие работников в управлении производством и собственностью, поощрение инициатив и новых идей	1. Поощрение инициативности сотрудников и внедрение их идей зависит в большинстве случаев от руководителей структурных единиц и их видения ситуации. Т.е. в некоторых подразделениях это поощряется, в некоторых игнорируется и исключается. 2. Управление собственностью: скорее исключает участие сотрудников в качестве партнеров по бизнесу.

Исходя из перечисленных проблем в модели 7S и описания качества трудовой жизни – отсутствует формализованная система мотивации. Введен учёт по времени прихода на работу, но отсутствует фиксация отработанного времени (сотрудники часто работают по 12 часов - но это не учитывается). Отсутствует система определения квалификации сотрудников. Определение вклада в общее дело носит субъективный характер и иногда зависит от личных симпатий. Соответственно, необходимо разработать данную систему и утвердить ее на коллективном собрании сотрудников и учредителей.

Контроль

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

2. Разработать систему аттестации сотрудников. Проводить ей с установленной периодичностью. По результатам принимать решение об обучении, премировании, повышении в должности, расширении полномочий.

3. Доработка внутренней ИС компании. Ведение отчетности, контроль выполнения и занятости, сравнительный анализ.

Оценка эффективности предлагаемых изменений

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

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

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

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

2.Анализ и оптимизация бизнес-процессов

2.1 Описание бизнес-процессов «как есть»

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

Разработка

Процесс разработки новых прикладных систем, как правило, состоит из следующих видов деятельности (Рисунок 3):

Постановка задачи;

Разработка;

Тестирование;

Документирование.

Процесс перехода между итерациями

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

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

Пронумерованная версия продукта (библиотеки, исполняемые файлы, база данных и пр.);

Описание функциональности, добавленной по сравнению с предыдущей версией;

Пронумерованные версии всех проектных документов на момент завершения итерации.

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

Процесс перехода продукта из разработки во внедрение и сопровождение

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

Ознакомление с проектной документацией;

Демонстрация программного продукта;

Обучение сотрудников внедрения работе с продуктом.

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

Оценка деятельности

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

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

Документ «Ведомость замечаний» свидетельствует о наличии вопросов и замечаний со стороны исполнителей какой-либо стадии к результатам предыдущей стадии. Чаще всего это также свидетельствует о низком качестве результатов, реже – о недостаточной квалификации исполнителей текущей стадии.

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

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

3.2 Изменения в организационно-штатной структуре

Изменения в организационно-штатной структуре представлены на рисунке 14.

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

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

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

Все подразделения, ответственные за внедрение и сопровождение, объединяются в Департамент сопровождения.

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

Также отдельно выделен Департамент профессионального развития персонала.

Рисунок 14. Новая организационно-штатная структура

3.3 Регламентирование деятельности

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

Регламентированию подверглись в первую очередь следующие процессы:

Оперативный мониторинг и информационная поддержка хода исполнения контрактных обязательств (Регламент приведен в Приложении 2);

Разработка программного обеспечения и выпуск дистрибутивов (Регламент приведен в Приложении 3);

Исполнение заявок на обслуживание и сопровождение (Регламент приведен в Приложении 4).

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

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

3.4 Перспективные направления автоматизации

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

Приоритетными являются нижеуказанные направления.

Информационная поддержка исполнения контрактных обязательств:

Учетные сведения о клиентах;

Реестр контрактов;

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

Кадровый учет:

Штатная структура компании;

Личные карточки сотрудников;

Приказы о назначении, увольнении, отпусках и пр.;

Табельный учет.

Делопроизводство и документооборот:

Входящая и исходящая корреспонденция;

Создание, согласование и утверждение внутренней документации;

Поддержка управления версиями документов.

Информационная поддержка процессов выпуска дистрибутивов и обновлений:

Учет дистрибутивов и стадий их выпуска;

Учет замечаний, реализованных в дистрибутиве;

Учет разовых обновлений;

Учет установленных у клиентов версий дистрибутивов.

Информационная поддержка процессов разработки, внедрения, сопровождения, технической поддержки:

Планирование деятельности;

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

З аключение

Поставленная задача оптимизации бизнес-процессов была решена в полном объеме; оптимизации подверглись основные процессы деятельности организации, а именно разработка, внедрение и сопровождение программного обеспечения.

Осуществлен переход от функционально-ориентированной к проектно-ориентированной штатной структуре компании.

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

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

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

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

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

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

Список использованной литературы

1.Амблер С. Гибкие технологии: экстремальное программирование и унифицированный процесс разработки. Библиотека программиста. СПб.: Питер, 2005.

2.Бек К. Экстремальное программирование. СПб.: Питер, 2002.

3.Браудэ Э. Технология разработки программного обеспечения. СПб.: Питер, 2004.

4.Даешь инжиниринг! М.: Издательство Эксмо, 2005.

5.Константайн Л., Локвуд Л. Разработка программного обеспечения. СПб.: Питер, 2004.

6.Крачтен, Филипп. Введение в Rational Unified Process. 2-е изд. М.: Издательский дом «Вильямс», 2002.

7.Кролл П., Крачтен Ф. Rational Unified Process – это легко. Руководство по RUP. М.: КУДИЦ-ОБРАЗ, 2004.

8.Липунцов Ю.П. Управление процессами. Методы управления предприятием с использованием информационных технологий. М.: Компания АйТи, 2003.

9.Хэлдман Ким. Управление проектами. М.: ДМК Пресс; Академия АйТи, 2007.

П риложение 1

Образцы внутренних документов

Структура документа «Постановка задачи»

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

1. Основные сведения

Название проекта, модуль

Название функциональности

Основания для разработки (контракт, пользователь, законодательство, и пр.)

Необходимость распространения на другие проекты

2. Описание назначения

3. Варианты использования

a. Название варианта использования, текстовое описание, UML-схема

b. Название варианта использования, текстовое описание, UML-схема

4. Диаграммы потоков данных

при необходимости

5. Диаграммы переходов состояний

при необходимости

6. Диаграммы классов

при необходимости

7. Проект пользовательского интерфейса

8. Ограничения

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

Структура документа «Заявка»

1. Основные сведения

Название проекта, модуль

Основания для разработки

2. Описание заявки

Текстовое описание содержания заявки, при необходимости – ссылки на скриншоты (для ошибок – обязательно)

3. Скриншоты

Копии экранов с выделенными и пронумерованными блоками (для ссылок в текстовом описании)

Структура документа «Тестовый пример»

1. Основные сведения

Номер заявки (из внутренней системы)

Название проекта, модуль

Название функциональности

2. Тестовые примеры

o Входные параметры: «название» = «значение»

o Последовательность действий пользователя

o Выходные параметры: «название» = «значение»

Структура документа «Описание реализации»

1. Основные сведения

Название проекта, модуль

Название функциональности

2. Описание алгоритма

Общее описание выбранных методов решения задачи

3. Реализация вариантов использования (если были указаны в «Постановке задачи»)

a. Название варианта использования, алгоритм реализации

4. Описание системных изменений

a. перечень измененных системных объектов (процедур, функций, модулей и пр.), при этом в коде указанных объектов обязательны следующие комментарии:

o все входные и выходные параметры, а также используемые внутри переменные должны иметь описание назначения;

o код должен быть разбит на логические блоки (при их наличии), снабженные комментариями об их назначении;

o при каждом изменении в начале после описания назначения должен вставляться комментарий с датой, автором и описанием изменения.

b. видимо, в основном для ИИС – перечень измененных классов, гридов, и пр.

5. Описание интерфейсных изменений

при изменении форм – скриншоты «что было» - «что стало» с выделением изменений

при добавлении форм – скриншоты этих форм

6. Диаграммы классов

при необходимости, видимо, в основном для ИИС

Структура документа «Краткое руководство»

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

Структура документа «Отчет о тестировании»

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

1. Основные сведения

Номер заявки (из внутренней системы) – в случае выполнения разовой заявки

Название проекта, модуль

Название функциональности

Дата тестирования, номер цикла тестирования

Суммарные данные (% успешно пройденных тестов)

2. Тест 1: пройден/не пройден

Должно быть:

o Входные параметры: «название» = «значение»

o Последовательность действий пользователя

o Выходные параметры: «название» = «значение»

Получено:

o Выходные параметры: «название» = «значение»

Комментарии

3. Тест 2: пройден/не пройден

Структура документа «Ведомость замечаний»

«Ведомость замечаний» составляется в двух случаях:

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

2. При внедрении и сопровождении системы.

Структура документа является следующей:

1. Основные сведения

Название проекта

Дата составления, последовательный номер, автор

2. Таблица замечаний

№ п/п

Замечание

Время - деньги. Создание команды разработчиков программного обеспечения Салливан Эд

Модель организационной структуры компании NuMega

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

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

Менеджеры проекта;

Программисты;

Тестировщики;

Разработчики документации;

Инженерные психологи;

Технологи по разработке ПО;

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

Группа менеджмента и маркетинга продукта;

Специалисты по технической поддержке ПО;

Администраторы бета-тестирования.

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

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

Из книги Стратегическое управление автора Ансофф Игорь

4.3.5. Характеристика проекта организационной структуры Как уже упоминалось в гл. 3.2, первые опыты создания действенной организационной структуры привели к образованию трёх функциональных групп материально-вещественной деятельности фирмы: производства, маркетинга

Из книги CIO новый лидер. Постановка задач и достижение целей автора Китцис Эллен

British Airways используют ИТ для смены структуры издержек в компании Компания British Airways (ВА) – крупнейший в мире международный авиаперевозчик – перевозит около 40 млн пассажиров в год, ее самолеты летают в 94 страны, в компании работает 46 тысяч человек. После трагических событий

Из книги Управление карточным бизнесом в коммерческом банке автора Пухов Антон Владимирович

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

Из книги Идеальный руководитель. Почему им нельзя стать и что из этого следует автора Адизес Ицхак Калдерон

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

Из книги Как преодолеть кризисы менеджмента. Диагностика и решение управленческих проблем автора Адизес Ицхак Калдерон

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

Из книги Настольная книга по внутреннему аудиту. Риски и бизнес-процессы автора Крышкин Олег

Ограничения классической пирамидальной организационной структуры Давайте посмотрим на типичную организацию и проанализируем ее с помощью модели PAEI.Типичная организация подобна пирамиде – она иерархична по природе. Иерархическая организация обладает определенными

Из книги Отличная компания. Как стать работодателем мечты автора Робин Дженнифер

Формирование организационной структуры ПВА «Незаменимых людей нет…» Но есть невосполнимые потери. Система организации и управления аудиторским процессом и организационная структура ПВА должны обеспечивать постоянное возобновление человеческого ресурса – хорошо

Из книги Как сэкономить на маркетинге и не потерять его автора Монин Антон Алексеевич

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

Из книги Как создавать инновации автора Пратер Чарльз

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

Из книги Практика управления человеческими ресурсами автора Армстронг Майкл

Модель «Три арены компании-инноватора» Проанализировав свои наблюдения, которые мы сделали в Центре креативности и инноваций (Center for Creativity and Innovation) компании DuPont в самые первые месяцы его работы в начале 1991 года, мы синтезировали модель “Три арены компании-инноватора»,

Из книги Хватит платить за все! Снижение издержек в компании автора Гагарский Владислав

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

Из книги Управление рисками, аудит и внутренний контроль автора Филатов Александр Александрович

Модель организационной эффективности работы – Mercer HR Consulting Налбантьян с соавторами (2004) описывают в своем труде модель организационной эффективности работы, созданную Mercer HR Consulting на основе следующих элементов: людей, рабочих процессов, структуры управления, информации и

Из книги Совершенная машина продаж. 12 проверенных стратегий эффективности бизнеса автора Холмс Чет

ОПРЕДЕЛЕНИЕ ОРГАНИЗАЦИОННОЙ СТРУКТУРЫ Все организации имеют некоторый тип более или менее формализованной структуры. Чайлд (1977) определял ее как содержащую «все случайные и закономерные приходящие в голову характеристики, которые помогают формировать поведение

Из книги автора

Организационно-функциональная модель компании Организационно-функциональная модель (ОФМ) компании – это документ, описывающий организационную структуру (с определенной детализацией) и функции, выполняемые подразделениями компании.Как правило, в ОФМ как документ

Из книги автора

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

Из книги автора

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

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

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

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

Рис. 14.1. Структура управления разработкой программных средств.

По каждому программному проекту назначается свой менеджер, который управляет развитием этого проекта. Ему непосредственно подчинены лидеры бригад разработчиков. Менеджер проекта осуществляет планирование и составление расписаний работы этих бригад по разработке соответствующего ПС (см. следующий раздел).

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

Наиболее употребительны три подхода к организации бригад разработчиков :

обычные бригады,

неформальные демократические бригады,

бригады ведущего программиста.

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

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

В бригаде ведущего программиста за разработку порученной программной подсистемы несет полную ответственность один человек, называемый ведущим программистом (chief programmer) и являющийся лидером бригады : он сам конструирует эту подсистему, составляет и отлаживает необходимые программы, пишет документацию к подсистеме. Ведущий программист выбирается из числа опытных и одаренных программистов. Все остальные члены такой бригады, в основном, создают условия для наиболее продуктивной работы ведущего программиста. Организацию такой бригады обычно сравнивают с хирургической бригадой . Ядро бригады ведущего программиста составляют три члена бригады: помимо ведущего программиста в него входит дублер ведущего программиста и администратор базы данных разработки. Дублер ведущего программиста (backup programmer) также является квалифицированным и опытным программистом, способным выполнить любую работу ведущего программиста, но сам он эту работу не делает. Главная его обязанность – быть в курсе всего, что делает ведущий программист. Он выступает в роли оппонента ведущего программиста при обсуждении его идей и предложений, но решения по всем обсуждаемым вопросам принимает единолично ведущий программист. Администратор базы данных разработки (librarian) отвечает за сопровождение всей документации (включая версии программ), возникающей в процессе разработки программной подсистемы, и снабжает членов бригады информацией о текущем состоянии разработки. Эта работа выполняется с помощью соответствующей инструментальной компьютерной поддержки (см. лекцию 16). В зависимости от объема и характера порученной работы в бригаду могут быть включены дополнительные члены, такие как

распорядитель бригады, выполняющий административные функции;

технический редактор, осуществляющий доработку и техническое редактирование документов, написанных ведущим программистом;

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

тестовик, готовящий подходящий набор тестов для отладки разрабатываемой программной подсистемы;

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

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

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

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

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

Различают два вида таких стандартов:

стандарты ПС (программного продукта),

стандарты процесса создания и использования ПС.

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

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

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

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

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