62
взаимодействием с пользователями, оборудованием и окружением
системы. Должны быть разработаны на языке C#.
Пользовательский интерфейс, реализуемый Front-end service
должен бать разработан на языке Type script с использованием
фреймворка Angular.
Мобильная платформа для Android устройств. Должна быть
разработана на языке Java.
Прикладной код, для исполнения на мобильной платформе.
Должен быть разработан на языке Java.
Система контроля качества должна включать в себя:
o Ручные методики тестирования через пользовательский
интерфейс. Должны быть реализованы с использованием
системы управления тестированием Testlink.
o Ручные методики тестирования мобильного приложения.
Должны быть реализованы с использованием системы
управления тестированием Testlink.
o Автоматизированные методики тестирования через
пользовательский интерфейс. Должны быть реализованы
средствами Selenium WebDriver с использование языка C#.
o Средства автоматизированного тестирования серверных
компонентов системы. Должны быть реализованы с
использованием языка C#.
o Средства автоматизированного тестирования Мобильного
приложения. Должны быть реализованы с использованием
языка Java.
Определим значимость выше указанных компетенций для разработки
всех трех продуктов и сведем выявленные требования к компетенциям единую
таблицу.
63
Под Ключевой компетенцией будем подразумевать набор навыков и
знаний, без которых любые работы по созданию продукта не возможны в
принципе. В команде разработки в обязательном порядке должно быть
достаточное количество специалистов, обладающих данной компетенцией.
Под Необходимой компетенцией будем подразумевать набор навыков
и знаний, без которых невозможно создать один из значимых компонентов
продукта. Специалистов с данной компетенцией крайне желательно иметь в
команде разработки, однако в силу не слишком большого объема работ
допустимо привлечь внешние.
Под Дополнительной компетенцией будем подразумевать набор
навыков и знаний, необходимый для создания второстепенного по значимости
компонента продукта. Отсутствие подобной компетенции является
блокирующим для создания продукта, однако в силу не слишком высокой
значимости и не большого объема работ нет необходимости иметь
специалистов с такими компетенциями непосредственно в команде,
достаточно привлекать их в качестве внешних ресурсов.
Под Недостающей компетенцией будем подразумевать набор навыков
и знаний, который кране желательно иметь для создания продукта, однако
отсевающий в настоящий момент и не блокирующий создание продукта.
Результаты исследования приведены в Таблице 5.
64
Таблица 5
Требования к компетенциям
WMS E5
TMS
WMS X5
Знание складской
логистики
Ключевая
компетенция
Не требуется
Ключевая
компетенция
Знание транспортной
логистики
Не требуется
Ключевая
компетенция
Не требуется
Разработка 1С
Ключевая
компетенция
Ключевая
компетенция
Не требуется
Разработка C#
Дополнительная
компетенция
Дополнительная
компетенция
Ключевая
компетенция
Разработка Java
Не требуется
Необходимая
компетенция
Необходимая
компетенция
Разработка Type
script, Angular
Не требуется
Не требуется
Необходимая
компетенция
Разработка C++/TQ
Дополнительная
компетенция
Не требуется
Не требуется
Разработка Java script
Необходимая
компетенция
Не требуется
Не требуется
Тестирование
автоматизированное
Недостающая
компетенция
Недостающая
компетенция
Необходимая
компетенция
Тестирование ручное
Недостающая
компетенция
Недостающая
компетенция
Необходимая
компетенция
Рассмотрим возможность сохранить проектную организационную
структуру в Департаменте развития, добавив еще одно подразделение.
Возможный результат такого преобразования приведен на Рисунке 15
65
Дублирование, низкая
загрузка та WMS X5 И TMS
Отсутсвие
Рисунок 15. Вариант создания нового подразделения с
сохранением проектной организационной структуры.
Источник: составлено автором.
Как видно из выше приведенной схемы мы получим необходимость
значительно дублировать ресурсы с одинаковыми компетенциями в
Департаменте развития либо же подразделения будут привлекать внешние
ресурсы. Дублирование ресурсов с одинаковыми компетенциями может
привести к значительному увеличению стоимости разработки и недозагрузке
ресурсов, обладающих компетенциями, являющимися дополнительными для
разработки данного продукта. В случае же привлечения внешних
подрядчиков, необходимые ресурсы будут отсасывать в компании, что как
было сказано выше приведет к риску утраты контроля над продуктами.
Таким образом, можно сделать заключение, что сохранение проектно-
ориентированной структуры в Департаменте развития и добавление в него еще
66
одного еще одного проектного направления со своими собственными
ресурсами является нецелесообразным.
Из приведенной таблицы 2.1 видно, что:
пять из шести компетенций, необходимых для разработки WMS
E5, так же востребованы в других проектах. При этом
Автоматическое и ручное тестирование является в этих проектах
Недостающей компетенцией;
Знание складской логистики является Ключевой компетенцией
для WMS E5 и WMS X5.
Разработка C# является ключевой компетенций в WMS X5 и
дополнительной в других проектах;
Разработка Java является необходимой компетенций в WMS X5 и
TMS;
Оба вида тестирования необходимой компетенций в WMS X5 и
недостающей в других проектах;
Представим пересечение компетенций графически. Результат приведен на
Рисунке 16.
67
1C
C#
WMS X5
TMS
WMS E5
Java
QA
Складская
логистика
C++/QT
Транспортная
логистика
Java
script
Type
script/
Angular
Рисунок 16. Диаграмма компетенций.
Источник: составлено автором.
Как видно из представленной выше диаграммы все три направления
имеют значительную область пересечения, при этом наибольшая области
совместных компетенций лежит в окружности WMS E5.
Java скрипт и С++/QT, находящиеся в окружности WMS X5 выделены
не случайно, хотя и являются необходимой и дополнительной компетенцией,
со своему существу они являются инородными основному стеку разработки,
68
так как, как было сказано ренее, они реализуют другую парадигму разработки,
более родственную C# и Java.
Исходя из значительного пересечения компетенций, требующихся для
развития трех направлений, а так же опираясь на выводы, сделанные в главе
один мы приходим к заключению, что для успешного развития всех трех
проектов с составе Департамента развития целесообразно изменить
организационную структуру департамента с проектной на матричную,
сформировав в нем три отдела: Отдел складской логистики, Отдел
транспортной логистики и Отдел развития высоконагруженных складских
систем, развивающий направление WMS X5. При этом будет разумно
сосредоточить в каждом из отделов компетенции, сродственные его Ключевой
компетенции. Так ключевой компетенцией для WMS X5 и TMS является
разработка на предметно-ориентированной 1С, и как следствие Архитекторы
данных направлений в первую очередь имеют глубокие познания в 1С, и
значительно меньше погружены в объектно-ориентированные языки, а
Архитектор WMS E5 в первую очередь обладает значительной экспертизой в
объектно-ориентированных языках, представляется полностью перевести
разработку на объектно-ориентированных языках в отдел
Высоконагруженных систем.
Так как ранее в составе Департамента развития никогда не существовало
отдела контроля качества, то представляется разумным создать группу
контроля качества в составе вновь создаваемого направления.
Новая структура департамента развития приведена на Рисунке 17.
69
Группа мобильных
решений
Рисунок 17. Предлагаемая структура Департамента развития.
Источник: составлено автором.
Таким образом, проанализировав деятельность Департамента развития
компании Акселот и требования к новому подразделения мы приходим к
выводу, что оптимальным вариантом включения нового подразделения в
состав Департамента развития является преобразование структуры
департамента из чисто проектной в матричную.
3.2 Выбор методологии управления производственным процессом
Для выбора методологии управления проектом необходимо в первую
очередь рассмотреть обратиться к традиционной для компании Акселот
стратегии развития продукта и учесть особенности нового проекта.
Традиционной для компании Акселот является стратегия «Быстрый старт»,
которую можно описать как набор следующих шагов:
70
Шаг 1. Имея достаточные компетенции в предметной области и обладая
пониманием основных запросов рынка, сформулировать базовые
функциональные и нефункциональные требования к продукту;
Шаг 2. В максимально короткие сроки разработать альфа-версию
продукта, обладающую базовыми функциональными возможностями и
частично реализующую нефункциональные требования;
Шаг 3. Выбрать одного или двух максимально лояльных компании
заказчика и предложить им участие в пилотных проектах. При этом заказчику
с одной стороны предлагается получить и испытать на своей площадке новый
продукт за цену значительно ниже рыночной, с другой стороны заказчик
понимает, что получаемый им продукт может оказаться не стабильным и
сопоставляет свои риски от использования нестабильного продукта с
преимуществами от получения новых возможностей. Фактически такой
заказчик становиться бета-тестировщиком продукта;
Шаг 4. В процессе обследования объекта автоматизации заказчика,
выявить недостающий в альфа-версии функционал и включить его в план
разработки; Совместить процесс внедрения продукта на объекте заказчика с
процессом разработки недостающего функционала;
Шаг 5. В ходе опытной эксплуатации продукта провести совместное с
заказчиком бета-тестирование и стабилизировать продукт; Параллельно
продолжать наращивать функциональные возможности продукта, используя
опыт и знания, полученные в ходе внедрения;
Шаг 6. После перевода заказчика в режим промышленной эксплуатации
приступить к активной продаже продукта, который на этот момент имеет уже
достаточно большой объём функциональности и в достаточной мере стабилен.
Автоматизированный объект обычно используется для референс-визитов
визитов потенциальных клиентов;
71
Такой процесс отнюдь нельзя назвать эталоном для подражания, однако
он имеет ряд преимуществ, таких как:
Скорость выхода продукта на рынок (хороший time-to-market);
Высокая мобилизация сил команды разработки на этапе параллельного
внедрения и доработки продукта. Вовлечение команды разработки в
процесс внедрения активное команды разработки и команды внедрения;
Глубокая вовлеченность заказчика в тестирование, высокая
заинтересованность заказника в скорейшем получении результат;
Высокая скорость реакции со стороны команды разработки на новые
выявляемые требования и ошибки;
Одновременно с этим такой процесс имеет очень серьезные недостатки:
Необходимость в наличии крайне лояльного заказчика;
Низкое качество кода, обусловленное приоритетом скорости разработки
и как следствие проблемы при дальнейшем развитии продукта;
Невозможность внедрения какой-то одной методологии управления
разработкой;
Остановимся на последнем пункте. Очевидно, что при подобном, по
сути итеративном подходе, единственным возможностью является
использование Adgile методологии. Однако, если на Шаге 2, когда список
целей известен и определены временные рамки, наиболее разумным является
использовать Scrum, то на Шаге 3 появляется значительное количество
вытесняющих задач и более удобным будет Kanban подход. Так же на шаге
два часто проявляются признаки экстремального программирования: парное
программирование, коллективное владение кодом, непрерывный факторинг,
очень короткие частые релизы. Так же Шаге 3 содержит в себе признаки RAD
подхода: раннее привлечение заказчика. Подобное комбинирование
методологий и подходов явным образом является существенным недостатком