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

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

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

— Первый источник — это наши пользователи: клиенты и партнеры. Запросы от них относятся, в основном, к развитию функционала. Второй — это наше видение, которое касается технических и инфраструктурных изменений, влияющих на работоспособность программы и качество продукта. Например, если мы реализуем передачу данных между «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 Чикаго Юнит». И у наших партнеров и клиентов появился выбор: работать со стабильным продуктом с минимальным количеством ошибок, или выбрать свежую версию, в которой реализованы новые интересные возможности.

Также в этом номере журнала «Мобильная Торговля» №46, 11/2014:

• Жалящая OSA
• Трансформация бизнеса: insights and inspiration 2020
• 4 точки роста FMCG-компании
• 5 заблуждений при запуске цифрового мерчандайзинга
• Прогнозируем сезонные промоакции правильно
• 6 ключевых трендов на рынке мерчандайзинга в 2020 году
• Soft skills или hard skills?
• БАТ: подключение сложного региона к глобальной экосистеме