CC BY
32
Sources:
1. Ansoff N. Strategic management / Transl. from English - M .: Economics, 1989. - 236 p.
2. Apshev ZB, Chechenova F.Zh., Misakov V.S. Strategic management of enterprise development as a basis for the formation of competitive advantages in a region // TerraEconomicus. - 2009. - T. 7. - No. 2-3. - S. 181-184.
3. The restless F.F., Smimova G.A. et al. The essence of the concept of "innovation" and its classification // Innovations. -1998. - No. 2. - S. 16-24
4. Valdaytsev S.V. Assessment of business and innovation. - M.: UNITY, 1997
5. Herter I.K., Misakov V.S. Features and main factors affecting the development of rural infrastructure of the mountain regions of the North Caucasus // TerraEconomicus. - 2012. - T. 10. - No. 3-2. - S. 123-126.
6. Gurzhiev V. Factors of innovative orientation of investments // Economist. - 2002. - No. 2. - S. 11-18
7. Kozelskaya A.V., Stepnov N.M. Scenario planning of the production program of an industrial enterprise on the basis of cognitive risk modeling // Modern Economics: problems and solutions. - 2016. - No. 5. - S. 57-82
8. Konina N.Yu. Mergers and Acquisitions in the Competition of International Companies: Monograph. - M.: TK VELBI, Prospect Publishing House, 2008
9. Misakov V.S. Some problems of ensuring the quality of information for the strategic management process // In the collection: North Caucasus in the system of strategic development of Russia materials of the All-Russian scientific-practical conference. -2011 .-- S. 60-65.
10. Misakov V.S. Comparison as a general scientific method of cognition // Bulletin of the Kabardino-Balkarian Scientific Center of the Russian Academy of Sciences. - 2007. - No. 3. - S. 16.
11. Misakov V.S., Adzhieva A.Yu. Features of transformation processes in the agricultural sector // Economic Bulletin of Rostov State University. - 2008. - T. 6. - No. 3-3. - S. 233-236.
12. Misakov V.S., Betrozov M.Kh. Factors and conditions conducive to increasing threats to the economic security of the regional economy // TerraEconomicus. - 2012. - T. 10. - No. 4-3. - S. 169-172.
13. Misakov V.S., Herter I.K. Criteria and indicators of sustainable development of territories // In the collection: Systemic crisis in the North Caucasus and the state strategy for the development of the macroregion materials of the All-Russian Scientific Conference. Executive Editor G.G. Matishov. - 2011 .-- S. 190-193.
14. Misakov V.S., Kovaleva I.N., Misakov A.V. Modeling the system of sustainable development of regional economic clusters. - Nalchik, 2014.
15. Misakov V.S., Rasumov V.Sh. The Formation of Priority Directions for Increasing Industrial Competitiveness of Processing Enterprises of the Agro-Industrial Complex // TerraEconomicus. - 2013. - T. 11. - No. 2-3. - S. 45-48.
16. Misakov V.S., Cherkesov S.Kh. The socio-economic consequences of the corruption of shadow relations in the regional economy // Bulletin of the Kabardino-Balkarian Scientific Center of the Russian Academy of Sciences. - 2013. - No. 6-2 (56). - S. 176181.
17. Forecast of scientific and technical development of the Russian Federation for the period until 2020 [Electronic resource]
18. Temrokova A.Kh., Misakov V.S. The current state and analysis of the organization of food industry enterprises in the agro-industrial complex of the Kabardino-Balkarian Republic // Issues of Economics and Law. - 2012. - No. 44. - S. 56-60.
К. Р. Назмутдинова - Казанский национальный исследовательский технический университет им. А.Н. Туполева-КАИ, Высшая школа технологий и менеджмента, kamnaz17@gmail.com,
K. R. Nazmutdinova - Kazan National Research Technical University A.N. Tupolev-KAI of Higher School of Technology and Management;
Л. Л. Надреева - доцент кафедры экономики, к.э.н., Казанский национальный исследовательский технический университет им. А.Н. Туполева-КАИ, nadreeva@mail.ru,
L. L. Nadreeva - Associate Professor, Department of Economics, Ph.D., Kazan National Research Technical University named after A.N. Tupoleva-KAI;
В.А. Абрамов - доцент кафедры экономики, к.э.н., Казанский национальный исследовательский технический университет им. А.Н. Туполева-КАИ, abramov@re-audit.ru
V.A. Abramov - Associate Professor, Department of Economics, Ph.D., Kazan National Research Technical University. A.N. Tupolev-KAI.
ПОВЫШЕНИЕ ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ РАЗРАБОТКИ IT ПРОЕКТА IMPROVEMENT OF ECONOMIC EFFICIENCY OF DEVELOPMENT OF IT PROJECT
Аннотация. Система оптимизации процессов может вдохнуть в работу компании новые силы, снизить нагрузку на сотрудников и, как результат, улучшить ключевые показатели. Разработка и внедрение в рабочий процесс нововведений - трудоемкая задача, однако одна из самых основных. Несмотря на большое количество исследований в области управления проектами, не существует универсального шаблона для всех сфер деятельности.
Сравнив различные методологии управления ресурсами в ИТ компании, были выявлены преимущества и недостатки каждой из систем. Объединив лучшие аспекты методологий, были внедрены пункты, повышающие эффективность разрабатываемого продукта в компании.
Был сделан вывод о том, что для решения выявленных проблем, основываясь на специфике деятельности организации, целесообразным является доработка текущей методологии реализации проекта - Scrum. Выбранный подход не требует высоких затрат и позволяет ускорить принятие изменений и задействовать такой ресурс как высокий уровень сплоченности коллектива организации.
Внесенные изменения благоприятно отразились на показателях компании.
Annotation. The process optimization system can breathe new energy into the work of the company, reduce the burden on employees and, as a result, improve key indicators. The development and implementation of innovations in the workflow is a laborious task, but one of the most basic. Conducted analytics is important for making changes and tracking the growth dynamics of company performance. Despite a large number of studies in the field of project management, there is no universal template for all areas of activity.
By comparing various resource management methodologies in an IT company, the advantages and disadvantages of each system were identified. Combining the best aspects of the methodologies, points were introduced that increase the efficiency of the developed product in the company.
To solve the identified problems, based on the specifics of the organization, it is advisable to finalize the current project implementation methodology - Scrum. The approach chosen does not require high costs and allows you to accelerate the adoption of changes and use for the good a high level of cohesion of the organization's staff.
The changes made had a positive effect on the company's performance.
Ключевые слова: Scrum, оптимизация, проект, внедрение, диаграмма Гантта.
Keywords: Scrum, optimization, project, implementation, Gantt chart.
Введение
Управление проектами в проектно-ориентированной компании можно рассматривать как часть общей системы управления всей организацией. Цель системы управления проектами в компании - организация работы внутренних процессов в компании, создание необходимых условий и ресурсов для успешной реализации проектной деятельности.
Было проведено исследование по выявлению проблем системы управления проектами. Организацию по разработке программных продуктов можно охарактеризовать как проектную, из-за специфики ее деятельности. Текущая ситуация внутри компании является серьезным препятствием эффективному функционированию.
Выявленные в ходе исследования организации проблемы можно детализировать и условно разделить на две группы: проблемы с организационной деятельностью и проблемы, влияющие на доход организации.
К первой группе проблем относится:
- несвоевременная актуализация важной информации и «сумбурность» информационных потоков;
- низкая подготовленность к изменениям требований Заказчика.
К группе проблем, влияющих на доход организации, относятся следующие проблемы:
- частое превышение изначальных сроков работ;
- низкий уровень внутреннего тестирования программного продукта;
- высокие риски, связанные с персоналом (болезни, увольнения).
Для решения данных проблем, основываясь на специфике деятельности организации, целесообразным является доработка текущей методологии реализации проекта - Scrum. Данный подход не требует высоких затрат и позволяет ускорить принятие изменений и задействовать такой ресурс как высокий уровень сплоченности коллектива организации.
Далее представлены мероприятия, которые направлены на совершенствование работы компании:
1. Внедрение методики оценки и планирования Poker Planning.
Poker Planning - это гибкая методика оценки и планирования, основанная на консенсусе. Agile команды по всему миру используют Poker Planning для оценки незавершенных продуктов. Poker Planning можно использовать с историческими точками, идеальными днями или любой другой оценочной единицей.
Чтобы начать сеанс покерного планирования, владелец продукта или клиент описывает задачу или функцию для команды. Каждый оценщик «держит колоду карт» Poker Planning со значениями, такими как 0, 1, 2, 3, 5, 8, 13, 20, 40 и 100. Значения представляют количество баллов, идеальных дней или других единиц, в которых оценивает команда. Оценщики обсуждают эту функцию, задавая вопросы владельцу продукта по мере необходимости. Когда функция полностью обсуждена, каждый оценщик выбирает одну карту, чтобы представить свое мнение. Все карты затем раскрываются одновременно.
Если все оценщики выбрали одно и то же значение, оно становится оценочным. Если нет, оценщики обсуждают свои оценки. Разработчики с высокими и низкими оценками должны обосновать их, приведя аргументы. После дальнейшего обсуждения каждый оценщик повторно выбирает оценочную карту, и все карты снова раскрываются одновременно.
Процесс планирования покера повторяется до тех пор, пока не будет достигнут консенсус или пока оценщики не решат, что гибкую оценку и планирование конкретного элемента необходимо отложить до получения дополнительной информации.
Большинство команд проводят сеанс Poker Planning после того, как будет написано начальное техническое задание или будет общее понимание продукта. Этот сеанс (который может занимать несколько дней) используется для создания первоначальных оценок, полезных для определения объема или определения размеров проекта.
Поскольку элементы бэклога продукта (обычно в устной форме) будут по-прежнему добавляться на протяжении всего проекта, большинство команд сочтут целесообразным проводить последующие сеансы быстрой оценки и планирования один раз за итерацию. Обычно это делается за несколько дней до окончания итерации и сразу же после ежедневного застоя, так как вся команда в это время вместе.
Команды, оценивающие в Poker Planning, постоянно сообщают, что они получают более точные оценки, чем с любой другой техникой, которую они использовали ранее.
Одна из причин, по которой Poker Planning приводит к лучшим оценкам, заключается в том, что он объединяет множество мнений экспертов. Поскольку эти эксперты образуют кроссфункциональную команду из всех дисциплин в программном проекте, они лучше подходят для задачи оценки, чем кто-либо другой.
Завершив тщательный обзор литературы по оценке программного обеспечения, Магне Йоргенсен, доктор философии из Simula Research Lab, пришла к выводу, что «люди, наиболее компетентные в решении задачи, должны оценить ее» [1].
Во-вторых, во время планирования покера начинается живой диалог, и его участники призывают оценщиков обосновать свои оценки. Исследователи обнаружили, что это улучшает точность оценки, особенно для элементов с большой неопределенностью, как мы видим в большинстве программных проектов.
Кроме того, было также показано, что просьбы обосновать оценки приводят к оценкам, которые лучше компенсируют недостающую информацию. Это важно для гибкого проекта, потому что оцениваемые пользовательские требования часто расплывчаты, поэтому могут интерпретироваться разработчиками по-разному.
Кроме того, исследования показали, что усреднение отдельных оценок во время гибкой оценки и планирования приводит к лучшим результатам, как и групповые обсуждения оценок.
2. Внедрение метода t-shirt sizes.
Это методика относительной оценки, обычно используемой в гибких проектах как одна из техник определения размеров задачи, что позволяет декомпозировать работу.
Вместо того, чтобы использовать несколько планировщиков, здесь предметы классифицируются по размерам футболок: XS, S, M, L, XL.
Термин происходит от того, как размеры футболок указаны в США. Вместо футболок с размерами 4, 5, 6 и т.д., есть только несколько размеров: Очень маленький (XS), маленький (S), средний (M), большой (L) и очень большой (XL).
При измерении задач команде разработчиков было предложено оценить, считают ли они объем работы очень маленьким, маленьким, средним, большим, очень большим или огромным. Получив оценку, команда разработчиков может более динамично думать о нагрузке, связанной с задачей. Размеры могут при необходимости получить числовое значение после завершения оценки.
Данная методика реализуется посредством следующих шагов:
1) Сделать S, M, L, XL карты
2) Владелец продукта объяснит задачу, которую нужно оценить, а команда разработчиков задаст вопросы, если у них возникнут какие-либо проблемы или неясности. Например, связанные с дизайном - нужно ли изучать что-то новое, прежде чем начинать дизайн / HTML / jQuery и т. д.?
Или связанные с написанием нового функционала - есть ли у нас готовая библиотека классов кода, или мы должны написать ее с нуля? Или связанные с тестированием - какие-либо конкретные настройки требуются для модульного тестирования?
Каждый разработчик дает задаче размер футболки. Выгоды:
- Это очень неформальная стратегия, и ее можно быстро использовать с большим количеством задач.
- Это популярный метод гибкой относительной оценки.
- Принудительная оценка в одном из фиксированных наборов размеров позволяет процессу идти быстрее.
- Это хороший способ ввести условия для относительной оценки.
- Это очень эффективно для оценки производственной задачи.
- Размеры футболок могут быть отличным способом познакомиться с относительной оценкой.
- Каждому размеру можно присвоить числовое значение (в часах).
Объединив рассмотренную методику с предыдущим пунктом - Poker planning, получаем собственную систему оценок всех входящих задач. Вместо стандартных карт Poker Planning используем карты с размерами футболок.
XS - 1 час,
S - 4 часа,
M - 1 рабочий день (8 часов),
L - 2 рабочих дня,
XL - неделя (5 рабочих дней).
Предложенный подход позволяет всей команде проекта оперировать оценками задачи в одной относительной системе. Данные оценки были приняты после обсуждения с техническим директором и техническими руководителями проектных групп. Таким образом, если задача превышает максимальный «размер» (оценивается более 5 рабочих дней), то она считается недостаточно декомпозированной и требуется вмешательство технического директора. Если разработчик решает оценить задачу в 10 часов, что является промежуточным между размерами карт M и L, то ему стоит выбрать один из вариантов:
- Декомпозировать задачу на более мелкие (Например, XS, XS, M). Нужно стремиться декомпозировать задачи до атомарных.
- Если возникают сложности при декомпозиции - выбрать карту большего размера (в данном случае - L).
Все в команде разработчиков будут поднимать свои карты одновременно. Команда разработчиков обсудит различия. Проектный менеджер объясняет задачи дальше или уточняет недопонимание, если таковое имеется. Команда начнет задачу, пока все не согласятся с одним размером. Рассмотрим систему оценок на реальном примере:
1. При проведении Poker Planning обсуждались две задачи: обновление интерфейса страницы регистрации и разработка страницы оформления заказа.
Два разработчика (Р1 -первый разработчик, Р2 - второй) взяли по странице и оценили их одинаковым размером L (16 часов) каждая. В ходе дискуссии выяснилось, что страницы имеют одинаковые элементы, которые может написать один программист, а второму останется только переиспользовать:
- поле подтверждения номера телефона - сложность задачи заключается в работе со сторонней системой отправки СМС;
- блок выбор города (автоматический выбор местоположения по Geo IP) - ввод с динамической подгруз-кой городов из базы данных, автоматическое определение местоположение с возможностью редактирования пользователем или выбора местоположения на карте.
При стандартном планировании такие страницы делаются последовательно с выделением общих компонентов, чтобы не делать двойную работу. Коллективно было решено разделить первичные задачи на следующие подзадачи для каждой страницы:
- Верстка страницы (M - 8 часов)
- Разработка компонента подтверждения номера телефона (S - 4 часа)
- Разработка компонента выбора города (S - 4 часа)
- Интеграция с API бекенда (XS - 1 час)
В таком случае, Р1 взял пункты 1, 2, 4; а Р2 - 1, 3, 4, соответственно для своих страниц. И получилось, что каждый из разработчиков потратит по 13 часов на свои задачи, что на 3 часа меньше первоначальной оценки. Параллельная работа двух программистов ускорит процесс работы и оптимизирует временные затраты.
2. Создание обобщенного бэклога.
Product Backlog - приоретизированный список бизнес-требований к будущему проекту. В настоящий момент требования от заказчика поступают в виде технического задания и дополняются по мере разработки.
В данном случае важно не «идти на поводу» у заказчика и все требования вне ТЗ собирать отдельным списком (документом). В таком случае заказчик получит свой проект без срыва сроков, и сможет начать вести деятельность. Так же данный пункт повышает лояльность клиента и остается в компании на техническую поддержку и доработку своего ресурса.
Было принято решение создавать новую задачу backlog. Пунктами чеклиста добавлять все пожелания Заказчика по мере их появления, выходящие за рамки сметы.
3. Мультипликатор.
В компании могут работать специалисты разного уровня (junior, middle, senior). Соответственно время на одну и ту же задачу будет затрачено разное.
Для каждого специалиста внедрен мультипликатор. Среднее время рассчитывается по уровню middle. Для каждого разработчика уровень определяется индивидуально техническим директором (Senior может сделать в 1.5 раза быстрее. Мультипликатор у такого разработчика будет 1.5). Junior разработчик будет делать дольше. Однако это «головная боль» компании - обучение и обеспечение роста и развития специалиста. Мультипликатор у него может быть 0.8. Остальные затраты компания берет на себя.
4. Использование тендерной площадки.
Задачи по технической поддержке ресурса нестабильны и различаются по масштабу и трудозатратам. При увеличении штата часть команды может остаться без работы в период «затишья». Если не увеличивать штат, то иногда команды не справляются с нагрузкой, что приводит к задержке сроков и другим негативным последствиям.
Использование тендерной площадки снимает вопрос с ресурсами - отдавая часть задач на подряд. Здесь же применяем предыдущие пункты.
При первичной реализации каждый участник тендера видел оценки других исполнителей. Тем самым мог снизить цену ради победы в тендере. Однако, как показала практика фрилансер может так сильно понизить оценку для победы в тендере, что это ниже реальных затрат на работу. Таким образом Исполнитель демотивиро-ван, может делать работу «спустя рукава» и в дальнейшем перестать участвовать в тендерах вообще.
Было принято решение скрыть оценку других исполнителей. Таким образом мы видим независимые оценки нескольких Исполнителей и выбираем оптимальную или обсуждаем с каждым причины выставленных ставок.
5. Еженедельные отчеты
Ежедневные планерки команды сокращали «полезное» время работы. Было принято решение сократить отчеты до 1 раза в неделю. Это позволяет руководителям оперативно следить за прогрессом команды, своевременно выявлять «слабые места», но не тормозят работу «пустой» болтовней.
6. Планирование ресурсов
Распределить разработчиков среди менеджеров бывает затруднительно. Метод «кто успел - тот и съел» показал себя не эффективным. Было принято решение разработать таблицу распределения ресурсов. Для каждой
задачи менеджер может запросить необходимого специалиста с указанием планируемого времени. Сбор запросов происходит еженедельно, в пятницу. Все данные поступают ответственному, который составляет таблицу. Руководитель может принять или отклонить запрос, перенести задачу на другого специалиста, изменить планируемое время.
Таким образом, мы получаем таблицу со списком специалистов и днями недели. Это облегчает планирование времени для разработчиков, на каждый день есть проекты с указанием времени, которое можно затратить на реализацию той или иной задачи.
Если задача была реализована быстрее - специалист переходит к следующему пункту.
После внедрения данной таблицы появились вопросы по доработкам. Исправление багов, перенос на боевой сайт и т.д. - это мелкие задачи, для которых необходимо от 10 мин до 1 часа. Планировать такие задачи сложно, т.к. время проверки Заказчиком предугадать сложно. Было принято решение использовать систему 7/1. Данная система подразумевает, что рабочий день специалиста - 7 часов, вместо 8. Запросы на ресурсы делаются исходя из такого расчета. Ежедневно у каждого специалиста остается один час на внесение мелких изменений в порядке живой очереди задач. Если таких задач нет, то специалист продолжает работу над последней задачей или может перейти к проектам следующего дня.
7. Диаграмма Гантта.
Диаграмма Гантта является наиболее наглядным способом визуализации задач проекта по временной шкале. Еженедельно актуализируя диаграмму мы показываем Заказчику все сдвиги, и легко можем диагностировать причины задержек, принять меры. Уже спустя две недели после внедрения были заметны изменения в поведении Заказчика. Стали более оперативно приниматься решения, проверяться задачи.
8. Регламент.
Заключительным аспектом в управлении ресурсами стало написание единого документа, регламентирующего действия коллектива компании. В нем подробно описаны и зафиксированы все принятые нововведения. Текущая версия однозначно требует доработки, например, регламентирование общения специалиста с менеджером или менеджера с Заказчиком, решение конфликтных ситуаций и т.д.
После презентации первой версии регламента было принято большое количество комментариев и предложений доработки рабочего процесса. Общая погруженность коллектива в обсуждение показала пути возможного развития компании с новой стороны.
Описанные доработки изначально были внедрены только для двух менеджеров проектов. У каждого из которых было по два проекта на разработку, три-четыре проекта на техническую поддержку. Отзывы были исключительно положительные. Было принято решение внедрить разработки для всей компании.
Сразу пошла положительная динамика:
- Сократились временные затраты менеджер проектов на контроль задач (соотношение факт/план). Стало больше полезного времени - появилась возможность брать больше проектов - увеличилась продуктивность и общая прибыль компании соответственно.
- Увеличилась лояльность Заказчика и его вовлеченность в процесс разработки, т.к. композиция задач стала более прозрачной. Разработчик отчитывается в задаче по каждому из пунктов. Заказчики с легкостью стали оперировать терминологией размеров футболок.
- Упрощение распределения задач по разработчикам с учетом их уровня квалификации по размерам футболок. Junior разработчику приоритетнее давать задачи маленьких размеров (XS, S). Middle и Senior могут брать более сложные задачи. Это минимизирует риски срыва срока и выполнения задачи.
- За счет внедрения Poker Planning улучшилась полезная коммуникация между специалистами и общее понимание проекта внутри команды. Это положительно влияет на развитие сотрудников в смежных областях.
- Увеличилось количество инициатив сотрудников при совместном обсуждении.
Вывод
Непосредственное внедрение методологии в компанию заняло 4 часа (вводная презентация + сессия вопросов - 2 часа, обсуждение появившихся вопросов в ходе первой недели работы - 2 часа). Затраты на внедрение разработок окупились уже в первый месяц использования продукта. Параллельно с внедрением нововведений собирается обратная связь коллектива для дальнейших доработок системы, при необходимости.
Несмотря на большое количество исследований в области управления проектами, нет универсального шаблона для всех сфер деятельности. Сравнив различные методологии управления ресурсами в ИТ компании, были выявлены преимущества и недостатки каждой из систем. Объединив лучшие аспекты методологий, были внедрены пункты, повышающие эффективность разрабатываемого продукта в компании.
Разработка и внедрение в рабочий процесс нововведений - трудоемкая задача, однако одна из самых основных. Проведенная аналитика важна для внесения изменений и отслеживания динамики роста показателей компании. Внесенные изменения благоприятно отразились на статусе компании и ее благосостоянии.
