Как грамотно организовать проектную работу? — Системные Технологии

Как грамотно организовать проектную работу?

Рубрика: Вопрос - Ответ

Текст: Татьяна Беспалова

Герман Шеремет,
технический директор
ГК «Системные Технологии»

Пять проектных команд ГК «Системные Технологии» включают 72 человека, которые работают с основными продуктами компании: «ST-Чикаго», «ST-Мобильная торговля», «ST-Репликация», «ST-Аналитика» и «ST-Локатор.web». Как соблюсти дедлайны и вовремя выпустить релиз — рассказывает технический директор Герман Шеремет.

— Как появляются идеи развития программ?

— Первый источник — это наши пользователи: клиенты и партнеры. Запросы от них относятся, в основном, к развитию функционала. Второй — это наше видение, которое касается технических и инфраструктурных изменений, влияющих на работоспособность программы и качество продукта. Например, если мы реализуем передачу данных между «ST-Мобильная торговля» и «ST-Чикаго», то заказчика не беспокоит, каким образом она устроена. Ему важно, чтобы обмен происходил быстро.

— Как отстраивается работа при ведении сразу нескольких проектов?

— Благодаря тому, что каждым проектом занимается выделенная команда, ребятам обеспечивается оптимальный фокус на целях и задачах. Есть у нас и группы сотрудников, которые работают между проектами. Например, аналитики. Если представить такую матрицу, в которой каждый проект — это отдельный столбец со своим графиком работ, то запросы аналитика — это строки, которые могут пронизывать больше двух столбцов. Причем запросы, затрагивающие несколько проектов, встраиваются в работу таким образом, чтобы требующийся функционал был готов в «ST-Чикаго» и в «ST-Мобильная торговля» одновременно.

— Какие роли есть в команде?

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

— И каждый в этой большой команде выполняет свой кусочек работы. Что происходит, если кто-то что-то не сделал вовремя?

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

— Как организована работа над запросом?

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

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

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

Разработка. Адская кухня

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

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

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

— Какие еще способы, кроме расстановки приоритетов, применяются?

— Если мы понимаем, что сильно недооценили какую-то задачу, то разбиваем ее на несколько частей и привлекаем других сотрудников. Но этот способ ограничен с точки зрения ресурсов: подключаемый сотрудник должен быть «в теме», иначе основному разработчику много времени придется потратить на объяснения, и общая скорость работы упадет. Поэтому основной инструмент — это все-таки выделение главного. Очень часто несущественный с точки зрения ценности для продукта «бантик» стоит значительного количества человеко-часов. На моей практике было такое, что после основательной проработки мы реализовывали пул требований на 60%. И оказывалось, что этого вполне достаточно, потому что оставшиеся 40% запросов потеряли свою актуальность в связи с появлением других возможностей и задач.

— Почему именно Microsoft TFS?

— Во-первых, это выработанный со временем стандарт компании. Во-вторых, среда разработки и написания кода для некоторых проектов. В-третьих, инструмент по управлению требованиями для аналитиков. Например, продукт «ST-Мобильная торговля» в качестве среды использует Qt Creator (кроссплатформенная свободная IDE для разработки на С, С++ и QML — прим.), а управление задачами по-прежнему строится в Microsoft TFS.

В 2002 году мы внедрили Rational Unified Process (методология разработки программного обеспечения, созданная компанией Rational Software — прим.). К 2010-му нас заинтересовали так называемые «гибкие» методологии разработки семейства Agile: Kanban, Scrum. И мы решили совместить смену технологии и основного инструмента разработки и полностью перешли на пакет Microsoft.

— Как это сказалось на эффективности работы?

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

— А почему при внесении изменений возникают ошибки?

— Это следствие. Для того, чтобы исключить ошибки, нужно прекратить развитие продукта и заниматься только его «причесыванием». Так мы поступили с «ST-Чикаго.Регион» и «ST-Чикаго.Юнит». И у наших партнеров и клиентов появился выбор: работать со стабильным продуктом с минимальным количеством ошибок, или выбрать свежую версию, в которой реализованы новые интересные возможности.

Поделиться статьей

При подписке на журнал «Мобильная торговля»

Использование материалов

Использование материалов журнала «Мобильная Торговля» возможно только при указании прямой ссылки на источник.

Редакция журнала

Татьяна Беспалова Татьяна Беспалова

Главный редактор журнала
«Мобильная Торговля»

Свои вопросы и пожелания вы можете отправить по адресу journal@systtech.ru



Логин:
Пароль:
Забыли пароль?