Методология в IT: прогнозируемый успех и формула командных достижений

Индивидуализм или созависимость? Гибкость или жёсткость? Вместе с экспертами разбирались в ключевых методологиях ведения IT-проектов. IT-специалисты как правило работают сообща. Даже те, кто живет фрилансом, так или иначе завязаны с командной структурой. От того, как выполняет свою работу каждый участник коллектива, зависит конечный результат. Чтобы проследить развитие проекта и не упустить ничего важного, руководители фиксируют данные на досках, в таблицах, календарях с напоминаниями и так далее. Но чтобы работа с подобными оргпомощниками была эффективной, их применение должно быть обусловлено избранной методологий управления проектом. Это поможет выработать единую стратегию и определить инструменты, с которыми будет работать вся команда. Как правило, метод выбирает руководитель, менеджер проектов. Он же ставит перед командой цели, задачи, контролирует их реализацию, повышает эффективность, оптимизирует процессы и многое другое. Выбранная методика так или иначе позволяет выработать единую стратегию администрирования, а также определить ряд используемых инструментов и принцип работы с ними. Как правило, это помогает менеджеру наладить работу так, что каждый член команды выполняет предсказуемое действие, а заказчик в итоге получает прогнозируемый результат в установленный срок. Оговоримся, что методик ведения проектов достаточно много, мы будем опираться на опыт постоянных героев нашей рубрики "Войти в IT". Например, проектный менеджер Иван Мальцев рассказал, что в компании 2ГИС, где он работает, используют несколько методологий. - У нас много команд, которые отвечают за разные части продукта. Транспорт, вебкарты, мобильные карты - у всех своя специфика, разные размеры команд и ключевые показатели. Поэтому каждый выбирает методологию, которая соответствует определённым целям, но чаще всего это Agile и методологии Scrum или Kanban, - уточнил Иван Мальцев. Scrum В своей команде Иван Мальцев использует Scrum, потому что важно и удобно работать "от спринта к спринту". Дело в том, что задачи, стоящие перед их командой динамично меняются и сложно что-то планировать на долгую перспективу. - Плюс мы постоянно правим процессы, чтобы велосити (скорость команды - показатель количества работы, которое Scrum-команда может выполнить за один спринт - прим. ред.) рос и мы могли делать всё больше задач для бизнеса. Ну и в целом Scrum достаточно удобный фреймворк для команды с понятными ролями и набором артефактов, - пояснил проектный менеджер. Ведущий HR-менеджер компании "Лайв Тайпинг" Кристина Попова назвала ключевые особенности данной методологии. Работа здесь разбита на спринты, длительность которых варьируется обычно от 1 до 4 недель, по проекту проводятся регулярные встречи команды. Как правило, они ежедневные. - Эта методология позволяет быстро реагировать на изменения в ходе проекта и вносить корректировки, - отметила Кристина Попова. Примечательно, что термин Scrum используют в регби. В игре он обозначает стартовое состояние команды перед вбросом мяча. В разработке же этот процесс строится на минимальном наборе мероприятий, ролей и артефактов. В результате команда в короткий срок предоставляет заказчику работающий продукт с новыми бизнес-возможностями, которые в приоритете. К плюсам метода scrum-разработки можно отнести то, что по окончании каждого спринта оценивается результат всей команды. К тому же сотрудники регулярно получают обратную связь и наставления руководителя. Работа проходит более динамично. И в этой системе можно быстро вносить изменения. - В конце спринта, спустя, например, две недели, проходит ретро. Тогда мы оцениваем, что прошло хорошо, что нет, что можно было бы улучшить, каких добились результатов, чтобы всем было понятно, к чему мы шли и к чему собственно пришли. Также в методе есть планинг. Он проводится в начале спринта. Не стоит забывать про ежедневные дейлики - это созвоны или общение в чате каждое утро в назначенное время, где каждый рассказывает, что он делал вчера и что намерен делать сегодня, - пояснила руководитель IT-проектов Мария Панченко . Однако у этого метода есть и недостатки. Например, проект может постоянно расширяться, требуя больше ресурсов, потому что нет чёткого планирования. При этом значимость каждого сотрудника достаточно высока, и, когда он уходит из команды, его сложно заменить или передать его работу другому члену команды. Agile Отметим, что Scrum построен на принципах работы такой гибкой методологии, как Agile. По сути, это не один какой-то подход в разработке, а семейство процессов. В основном он определяет ценности и принципы, которыми в итоге руководствуется команда. Этот метод не содержит практических советов и держится в основном на взаимодействии людей, работающих над проектом. - Agile предполагает, что команда должна быть готова к изменениям в проекте в любой момент, что удовлетворение потребностей заказчика важнее, чем какие-то изначальные договорённости. В этой методологии важнее, чтобы продукт работал, а не был детально задокументирован. И формальные процессы не так важны, как командное взаимодействие, - пояснила Мария Панченко. - К сожалению, этот подход несёт в себе существенную уязвимость. Если ты дальше не придерживаешься процессов, которые знает и понимает вся команда, то можно потеряться в сроках, целях, ожиданиях заказчика и команды друг от друга. Часто эту методологию критикуют за то, что она пренебрегает созданием плана развития продукта, а значит и управлением требованиями, которые этот план и формируют. В конце каждой итерации заказчик может неожиданно выставить новые требования. И часто новые запросы противоречат архитектуре уже созданного продукта. А это приводит к авралам и многочисленным переделкам. Также из недостатков - практически полная невозможность сменить состав команды, потому что у каждого участника процесса большая вовлечённость в цикл. Но у Agile есть и существенные преимущества. Например, работая с этой методологией, команда изначально готова к любым изменениям. Есть открытая обратная связь от заказчика продукта. И в целом, когда процесс ориентирован на команду и лично на каждое звено в ней, то сотрудники становятся более мотивированы, а значит растёт работоспособность. Waterfall Agile и другие гибкие системы управления проектами создавались, скорее, как противовес давно используемой, и не только в IT, жёсткой методике Waterfall. Если в гибкой методологии можно и нужно вносить изменения, то в Waterfall это невозможно. - Это каскадная модель - все задачи на проекте выполняются последовательно, их нельзя менять местами. Если команда следует Waterfall, то она не может вернуться назад и внести корректировки на ходу. В итоге ей приходится мириться с допущенными ошибками до конца последнего этапа и лишь затем планировать исправления, - пояснила Кристина Попова. В этой методологии процесс разработки идёт потоком, практически - "водопадом". Такие фазы, как анализ требований, проектирование, реализация, тестирование, интеграция, поддержка идут исключительно последовательно друг за другом. Пока один отдел не закончит работу, другой не может приступить к своим задачам. В этой жёсткой методологии проекту дают строго очерченную структуру и ставят конкретные сроки её исполнения. Такой подход ставит каждого члена команды в жёсткие созависимые условия. IT-проекты требуют большей гибкости процесса, поэтому Waterfall мало подходит сфере информационных технологий, но при этом имеет место. Ещё один отрицательный момент этого метода - результат работы, в отличие от того же Scrum’а, виден только в самом конце. Но у этого метода есть и ряд преимуществ. Например, новых членов команды можно ввести в проект быстро и просто, потому что все задачи поставлены заранее и не изменяются. Заказчик взаимодействует на старте проекта, объясняя требования, и затем только в финале. Ещё один плюс: строгая фиксация сроков и финансирования. Но отсутствие гибкости практически полностью перечёркивает вышеперечисленные достоинства. Kanban Есть ещё одна система управления проектами, которая используется не только в IT, но и в строительстве, ритейле, банковской сфере и так далее - Kanban. Кстати, об этой методологии мы недавно писали в рамках материала про самоорганизацию . Примечательно, что в этом методе используют доску с карточками. - Kanban основан на визуализации задач с помощью записи на доске (виртуальной или физической): столбцы представляют собой разные этапы проекта. По ходу процесса разработки стикер или карточка, представляющая проект, перемещаются от одной фазы к другой, пока все задачи не будут выполнены, - пояснила Кристина Попова. Этот процесс удобен тем, что может использоваться как отдельно, так и быть встроенным в большую систему, быть внутри другой методологии. Также с помощью Kanban работать над проектом можно удалённо всей командой. Из преимуществ - хорошая визуализация процесса и простая структура работы. Также на доске видна загруженность каждого члена команды. Однако есть у Kanban’а и свои недостатки: метод не подходит для долгосрочного планирования (скорее для фиксации текущих задач) и неудобен в работе большой команды. Что же выбрать? По мнению нашего постоянного эксперта Кристины Поповой, если коротко сравнить, цель в Scrum - закончить спринт, в Kanban - задачу, а в Waterfall - завершить все этапы проекта последовательно. - Обычно для команд, которым нужно быстро доставлять большое количество фичей, ставят Scrum. Потому что ключевая метрика - это количество выпущенных фичей в спринт. А команды, которые в большей степени работают на поддержке и им важна стабильность продукта, используют K anban. Здесь ключевая метрика - это среднее время работы над задачей, что фокусирует не на целых спринтах, а на отдельных задачах, которые могут быть критичны пользователю в данный момент, - уточняет проектный менеджер Иван Мальцев. Эксперты отмечают, что гибкие методологии более популярны в стартапах и в тех компаниях, которым нужно опережать конкурентов ежедневно на быстро меняющемся рынке. А для построения продукта по уже понятному техзаданию лучше использовать классические и более жесткие подходы. Опытным командам, порой имеет смысл экспериментировать с процессами и не стесняться перестраиваться по ходу реализации проекта, чтобы достичь своих целей. Проектный менеджер Иван Мальцев такдже упомянул о подходе RUP или Rational Unified Process. Методология ориентирована на создание высококачественных продуктов с учётом рисков и требований заказчика. В её основе заложено непрерывное устранение основных рисков, а также концентрация внимания на выполнении требований заказчика. Команда уже заранее предполагает, в каких требованиях, проектных решениях и на каком этапе реализации проекта могут быть изменения. Уже на ранних стадиях реализуется и тестируется компонентная архитектура. Ключевая роль в команде в этой методологии принадлежит ожидаемо архитекторам. Командам, которые только образуются, наш эксперт советует использовать для начала фреймворки в чистом виде. - Так проще распределять роли и стартовать без пробуксовок. А уже дальше от спринта к спринту добавлять или заменять практики на более подходящие. Если резюмировать, то выбор подхода к управлению проекта похож на построение архитектуры продукта. Нужно проанализировать вводные, цели и условия, в которых находится команда, и принимать решение, не забывая, что рынок меняется и нужно быть готовым к этим изменениям, - подытожил Иван Мальцев. Изображения созданы с помощью Midjourney