72
не получается в полной мере воспользоваться преимуществами ни одной из
них, а недостатки экстремального программирования крайне заметны.
Рассмотри особенности проекта WMS E5. Так как было решено, что в
первых версиях WMS E5 будет копировать уже существующую WMS X5, то
список функциональных требование представляется известным. Так же имея
в активе опыт пилотных проектов WMS X5, мы можем определить
функциональные границы для первой версии WMS E5, а так же создать план
развития продукта. Как следствие, мы можем выбрать для пилотных проектов
заказчиков, требования которых укладываются в определенные нами
функциональные границы. Нефункциональные требования, такие как
производительность, желательна скорость отклика, требования к
масштабированию системы нам так же хорошо известны.
Таким образом главным отличием традиционного для компании
Акселот подхода к созданию нового продукта от подхода, которые мы можем
реализовать при разработке WMS E5 является хорошее понимание требований
к продукту и графика реализации этих требований, что позволяет нам
разработать Road map, разбить план развития продукта на этапы, определить
цели и задачи каждого этапа, опасаться функциональность, которую
необходимо разработать, чтобы достичь поставленных целей. Следовательно
мы можем прогнозировать четкие релизные периоды, отсутствие
«вытесняющих» задач.
Далее обратимся к ожидаемой структуре нашего продукта. Основными
компонентами Информационный системы WMS E5 будут являться:
Платформа. Набор модулей, обеспечивающий совместную работу
компонентов ИС в едином информационном пространстве. Условно
может быть разделена на базовую платформу, обеспечивающую запуск
и взаимодействие компонентов ИС и расширенную, отвечающую за
73
горизонтальное масштабирование, обеспечивающую эксплуатацию в
режиме SaaS;
Ядро. Набор модулей, обеспечивающих управление объектами данных.
Условное может быть разделено на базовое ядро, выполняющее CRUD
операции и кэширование и расширение ядра, отвечающее за
высокоскоростные поисковые функции, реактивное взаимодействие
компонентов системы;
Уровень бизнес-логики. Множество модулей, отвечающий каждый за
свой набор бизнес-функций;
Интерфейс пользователя. Множество модулей, отвечающий каждый за
свою операцию или функцию администрирования;
Мобильная платформа. Отдельная подсистемы, состоящая из множества
модулей, отвечающих каждый за свою операцию. На первом этапе
будет эксплуатироваться мобильная платформа от WMS X5, что будет
достигнуто стандартизацией API. На втором будет разработана более
новая платформа, так же совместимая с WMS X5.
Рассмотрим зависимости между компонентами информационной системы.
Диаграмма зависимостей приведена на Рисунке 18.
Платформа
Ядро
Бизнес логика
Интерфейс пользователя
Мобильная платформа
Компонент WMS E5 Зависимость
База Расширение
Функции
База
Mobile X5, Mobile E5
Функции
Расширение
Рисунок 18. Диаграмма зависимостей компонентов WMS E5.
Источник: внутренние документы Департамента развития
компании Акселот «Архитектурные требования к WMS E5»
74
На первый взгляд в проекте очевидно присутствует зависимости,
требующая waterfall подхода к разработке, однако при более внимательном
подходе видно, что таковыми являются только базовые модули ядра и
платформы, все остальные компоненты могут развиваться самостоятельно и
последовательно, а разработка базового ядра и базовой платформы могут
являться инициирующими итерациями процесса разработки.
Сразу откажемся от рассмотрения RAD и XP методологий, так как мы
планируем плановую проектную разработку, у нас нет необходимости
работать в условиях сильных ограничений по срокам и по бюджету, а качество
кода и стоимость его дальнейшего поддержания и развития является для нас
значимым фактором.
Необходимость постепенно развивать функционал продукта, пошагово
добавляя в него новые функциональные возможности, либо расширяя уже
созданные модули указывает нам, что разумно будет обратиться к
итеративным Agile методологиям, наиболее распространенными из которых
на сегодняшний день являются Scrum и Kanban.
Как уже говорилось выше, мы планируем создавать и развивать продукт
в соответствии с четко определенным Road map в рамках оговорённых
релизных периодов и в отсутствии вытесняющих задач, следовательно у нас
нет ярко выраженной необходимость в применении Kanban методологии более
строгая по сравнению с Kanban Scrum методология лучше соответствует
нашим целям.
Таким образом взяв в расчёт наиболее распространенные на
сегодняшний день методологии управления процессом разработки и
используя метод исключения мы пришли к выводу, что оптимальным для нас
является применение Scrum.
Рассмотрим более внимательно возможность и особенности применения
Scrum на проекте WMS E5 в компании Акслот. Первой и очевидной проблемой
75
для нас является отсутствие опыта, навыка и культуры применения этой
методологии, однако, так как мы с самого начала планируем применить ее во
вновь формируемом подразделении, мы можем учесть это на этапе подбора
персонал, сделав фокус на соискателей, ранее работавших в Scrum командах и
на личностных качествах кандидатов, в том числе склонности к командной
работе. В случае же перевода старых сотрудников компании в новый отдел,
руководителю необходимо приложить особое усилие для того чтобы не
допустить негативного влияния ранее накопленного опыта на рабочий процесс
в команде.
Другой проблемой может стать то, что для достижения высокой
эффективности Scrum команды необходима ее внутренняя самоорганизация,
отсутствие этого процесса сведет все усилия на нет. Главным риском здесь
может стать тот сегмент рынка труда, на котором предпочитает работать
компания Акселот. Пытаясь набирать сотрудников с высоким уровнем
интеллекта, воспринимающих разработку ПО как свое призвание и при этом
стараясь оставаться в среднем диапазоне заработной платы, по возможности
держась около его нижней границы, компания часто берет на работу
сотрудников, обладающих различными личностными особенностями не
слишком хорошо совместимыми с понятием самоорганизация. Для того чтобы
сделать работу таких сотрудников более эффективной, необходимо вести в
стандартную Scrum команду роль лидера. Существует множество мнений на
этот счет, в том числе есть мнение, что наличие этой роли прямо противоречит
идее Scrum, однако сама идеология Adgile подразумевает гибкость, а Scrum
является не стандартом, а набором принципов, что в конечном итоге позволяет
нам вносить в него модернизации.
Будет правильно совместить роль лидера – Team lead с ролью Scrum
master, таким образом не создавая в команде конфликта интересов между
формальным и неформальным лидером. В обязанности Team lead будет
входить:
76
Контроль за соблюдением сроков;
Пиритизация задач;
Контроль за правильностью назначения задач – своевременно выявлять
задачи, взятые сотрудником, не имеющим достаточных компетенции
для их решения, и снятие их с сотрудника;
Контроль за эффективностью использования рабочего времени и
ресурсов;
Оказание экспертной помощи разработчикам и обучение сотрудников;
Своевременное выявление и эскалирование проблем;
Исходя из предполагаемой сложности и объема работ определим
количественный состав подразделения. При этом необходимо заранее
понимать, что решение будет приниматься исходя из эмпирических данных и
опыта, накопленного компанией и непосредственно руководителем будущего
подразделения. Как следствие количество сотрудников может в
подразделении в дальнейшем может быть скорректировано. Так же мы будем
опираться на рекомендации, методологии Scrum.
Определим предпосылки:
Оптимальным размером Scrum команды является 5-9 человек[9];
Команда должна включать в себя Scrum мастера и Product owner’а[12];
Эмпирически выведенное отношение количества разработчиков к
количеству тестировщиков находится в диапазоне от 1:3 до 1:5;
Мобильное приложение, разрабатываемое на C++/QT на момент
формирования подразделения уже создано и находится в состоянии
альфа-версии. Однако сложность, заложенная в мобильное
приложение, различные тонкие эффекты, возникающие при работе
приложения на OEM устройствах, необходимость поддержать работу
мобильного приложения на старых устройствах в режиме жесткой
77
экономии аппаратных ресурсов требует очень высокой квалификации
прогарммиста;
Загрузка разработчиков Java, привлекаемых на подряд ранее в среднем
составляла 150 человеко-часов в месяц;
Максимальная нагрузка при разработке высоконагруженных
приложений ложится на разработчиков серверной части;
Клиентская часть (фронт-энд) WMS системы не отличается сложность,
фактически его задачей является предоставление типовых
инструментов редактирования нормативно-справочной информации и
доступ к отчетности;
Основными задачами тестировщиков будут являться: разработка
ручных методик, разработка автоматизированных методик, регулярное
выполнение ручного регрессионного тестирования;
Тестировщики будут регулярно задействованы как в проекте WMS E5,
так и в проекте WMS X5;
Исходя из вышеуказанных предпосылок и опираясь на опыт компании в
разработке систем подобного класса определим примерный количественный
состав подразделения:
Руководитель подразделения – 1 человек;
Архитектор информационных систем – 1 человек;
Разработчики C# - 5 человек уровня не ниже Middle. Основная
команда разработки;
Разработчик С++/QT – 1 человек уровня Senior. Доработка и
стабилизация существующего решения, адаптация мобильных
решений под широкий спектр устройств;
Разработчик Java для Android – 1 человек, уровня не ниже Middle.
Соответствует ранее имевшейся загрузке;
Тестирование - 3 человека;
78
Таким образом, с учетом особенностей проекта и особенностей рынка
труда, на котором работает компания оптимальной методологией для
управления процессом разработки в создаваемом отделе является
модифицированный Scrum с введением роли Team lead в команде разработки.
3.3 Технология создания нового подразделении
После того, как основные стратегические решения, такие как внесение
изменений в организационную структуру и выбор метрологии управления
производственным процессом приняты, необходимо решить тактические
задачи: определить количественный и профессиональный состав нового
подразделения, выбрать инструменты для управления производственным
процессом, составить график комплектации отдела, определить источники
прудовых ресурсов.
Как нам известно из ранее проведенных исследования, в соответствии со
спектром решаемых задач в составе подразделения должны присутствовать
специалисты со следующими компетенциями:
Разработка серверной части, C# на платформе .Net Core
Разработка клиентской части React, Angular, Vue js
Разработка Android Java
Разработка С++/QT
Специалисты ручного и автоматизированного тестирования
Так же, поскольку проектирование высоконагруженных
информационных систем является отдельной компетенцией, отличной от
разработки, в состав подразделения необходимо включить должность
Архитектор информационных систем.
В сложившейся в компании Акселот практике принято совмещение роли
Архитектора и руководителя направления. Данная задача была решена
приглашением на роль руководителя направления автора настоящей работы,
имеющего многолетний опыт как проектирования информационных систем,
79
так и управления IT проектами. Именно перед автором этой работы и была
поставлена задача создать новое IT подразделение, о чем и написана работа.
В составе Scrum команды необходимо наличие двух выделенных ролей:
Scrum мастер и Product owner. При этом на роль Scrum в соответствии с
принятом ранее решением о модернизации методологии необходимо выбрать
сотрудника, обладающего одновременно навыками Scrum мастера и Team
lead’а. На роль Product Owner желательно выбрать сотрудника, имеющего
навык разработки, внедрения или эксплуатации WMS систем.
В состав группы тестирования должен необходимо выбрать сотрудника,
обладающего навыками разработки автоматизированных систем
тестирования, сотрудника, обладающего навыками разработки сценариев
тестирования и сотрудника, обладающего лидерскими качествами для
исполнения роли Test lead. Возможно так же выбрать сотрудника,
совмещающего в себе любые два из указанных навыков. На роль сотрудника,
выполняющего ручное тестирование допустимо принять кандидата без опыта
работы в тестировании, но обладающего достаточной компьютерной
грамотностью и обладающего необходимыми личностными качествами.
Следующим шагом необходимо определить источники привлечения
рабочей силы. Таковыми могут стать: внутренние ресурсы компании,
сотрудники привлеченные на московском рынке труда, сотрудники,
привлеченные в регионах, в которых у компания имеет региональные
отделения. Однако стоит учесть, что единственным региональным
отделением, в котором сосредоточены серьёзные ресурсы по разработке ПО
является отделение Акселот-Киров. Было бы неразумным набрать
разработчиков в прочих региональных отделениях в силу следующих причин:
кадровые службы не имеют навыка набора программистов. В офисах нет
подготовленных рабочих мест, соответствующим внутренним стандартам
рабочего места программиста. Для обеспечения высокой производительности
работы разработчиков ПО, увеличения качества кода, повышению их
80
лояльности, у желательно создать для них комфортную среду, в том числе
окружить коллективом сотрудников, занимающихся тем же родом
деятельности, в котором они смогут получить консультацию от коллег,
обсудить интересующие их технические вопросы, просто пообщаться на темы,
характерные для индивидуумов со схожим образом мышления. Подобное
неформальное общение очень часто приводит к значительному повышению
культуры разработки ПО. Напротив, разработчики, не имеющие возможности
своевременно обратиться за советом к коллегами, оторванные от близкой их
образу мышления информационной среды часто затормаживаются в своем
развитии, принимают сомнительные решения при разработке кода, теряют
интерес к своей работе, что негативно сказывается на общем результате
команды.
Таким образом были у нас есть четыре основных источника рабочей
силы: рынки труда города Киров и города Москва, внутренние ресурсы в
Московском и Кировских офисах компании Акселот.
Как мы могли видеть ранее в ходе исследования компании Акселот, ее
основная деятельность связана с разработкой программных продуктов на
языке 1С. Обследование ресурсов московского офиса показало, что в нем
отсутствуют разработчики на языках, отличных от 1С. Исследование
Кировского офиса показало наличие двух Full stack разработчиков имеющих
развитые компетенции в разработке на языке C#. Более того эти разработчики
привлекались ранее для решения различных задач при разработке и внедрении
WMS систем.
Исследование рынка труда, выполненное Отделом персонала на момент
принятия решения о создании нового подразделения, а так же обзор
аналитических источников [23] показал показало следующее распределение
зарплат разработчиков уровня Middle в городе Киров и городе Москвы.
Результат приведен в Таблице 6.
81
Таблица 6
Уровни зарплат разработчиков в городах Киров и Москва
Город
C#
Москва
80.000-120.000 р
Киров
60.000-80.000 р
Однако дальнейшее исследование рынка г. Киров показало, что его
средняя емкость рынка разработчика C# уровня Middle составляет 10-12
резюме в месяц при этом на рынке действуют следующие сильные игроки:
Luxoft,
EPAM
ELMA
ASPOSE
ПРАВО.РУ
WaveAccess
Force центр разработки
При этом все вышеуказанные компании применяют агрессивные методы
поиска, в том числе прозвон сотрудников компаний-конкурентов, поиск среди
контактов в соцсетях среди сотрудников компаний- конкурентов, сбор
рекомендаций.
Компаний Luxoft и EPAM предлагают только релокация, но при этом
предлагаемые зарплаты значительно выше рынка, остальные игроки
предлагают в том числе удаленную работу, с заработной платой на 25% - 40%
выше, чем при такой же работе в офисе.
Как видно из выше описанных фактов, несмотря на относительную
дешевизну разработчиков в г. Киров их поиск представляется достаточно
сложной задачей. В этих условиях эффективным вариантом работы HR
является переманивание сотрудников на более высокую заработную плату.
Однако появление в кировском отделении компании Акселот сотрудников с