Разработка по SCRUM - это проект?

Современные подходы к разработке программных продуктов и информационных систем всё чаще предполагают использование гибких (Agile) методологий и моделей - SCRUM, Kanban, XP и т.п. Но то такое «разработка ИТ-продукта»? Это проект? Процесс? Функция? И можно ли считать разработку по SCRUM проектом?

Итак, чем же является разработка ИТ-продукта (автоматизированной информационной системы, программного обеспечения, приложения)? Это проект? Процесс? Функция?

Однозначного ответа на этот вопрос, скорее всего, нет. И вот почему.

Начнём с определения проекта. Что такое «проект»? По PMBoK («библия» проектного менеджмента) проектом считается «временное предприятие, направленное на создание уникального продукта, услуги или результата», и характеризуется проект тем, что он:

Если этого нет, то это уже не проект, а процесс.

Но процесс может быть как предопределённым (2+ уровень зрелости бизнес-процессов в организации), так и стохастическим (ad hoc - "к случаю"). Серийное производство, типизированные процессы, не имеющие при этом чётких временнЫх рамок — это не проект. К таким можно отнести некоторые этапы жизненного цикла создания ИТ-продукта (например, техподдержка первого уровня после запуска в постоянную эксплуатацию, или функции бэк-офиса)

В своей практике я сталкивался и с процессами (например, мы делали, параллельно исследуя и разрабатывая «что делать» и «как делать», принципиально новую информационную систему — я тогда работал в отраслевом НИИ, шла работа по созданию АСУ отрасли, «всё было впервые и вновь», у нас был блок аналитики данных, и мы последовательно добавляли всё новый функционал, о возможности создания которого ещё недавно даже не думали), и с проектами (например, разработка веб сайтов в веб-студии — уже после того, как ушёл из НИИ). В процессах, как правило, не было чётких временных рамок, не считая некоторых нюансов оформления НИР — сроки и смета, конечно, были, и были некие промежуточные артефакты типа работающего ПО и документации, но требования к ним явным образом не предъявлялись, кроме того, что они должны быть; сам же «проект» продлевался из года в год — и это было нормально и правильно, потому что это была тематика лаборатории.

Была и разработка (как процесс) внутрикорпоративной ERP на 1С в компании, где я работал после НИИ — к моему счастью, там я уже не программировал и даже не проектировал архитектуру продукта, за мной была только постановка задачи и соучастие («C» в матрице ответственности RACI) в проектировании решения. К не меньшему счастью, обходились и без выходной документации (для себя же!). Там тоже не было временнЫх границ — только локальные «недодедлайны», да приоритезация задач. Сколько фирма жила (ну, не с самого рождения, конечно), столько и делался продукт. Последовательно «обрастая мясом».

Какую методологию можно было (бы) применить к таким РАБОТАМ (проекты, процессы): где лучше скрам, где водопад? Не готов однозначно сказать. Хотя по матрице Стейси и модели Кеневин (Cynefin) примерно понимаю, какой проект/процесс где должен был бы быть.

Но если речь всё же о проектах, то я бы предпочёл всё же водопад. Или RUP. Сознательно выделив блок анализа в отдельный «предпроектный» проект с фиксацией (с заказчиком) договорённостей и выявленных требований в виде ТЗ (по которому потом и ПМИ написать, и приёмку пройти можно).

Ведь по той же модели Кеневин, SCRUM хорош в том квадранте, где ещё нет хаоса, но уже есть некая неопределённость, когда в начале работы нельзя точно сказать, что мы хотим получить в итоге.

Если признать и принять неопределённость (что, зачастую, скорей, политическое решение, нежели объективно обусловленное), то — да, наверно, лучше аджайл со скрамом.

Но вот вопрос (тут стОит обратиться к сфере управленческого консалтинга и стратегическому планированию, даже ещё выше — к миссии и ценностям компании): а всегда ли надо принимать неопределённость как априорную и непреложную данность, или это только наше нежелание навести порядок? Мой личный опыт подсказывает — иногда достаточно чуть жёстче поставить себя с заказчиком, не давая ему вольности для вариативности, чтобы упростить работу и гарантированно сделать именно то, что заказчику нужно, и сдать ему это в срок и к обоюдному удовольствию. Иначе будет, как у Пушкина в «Сказке о рыбаке и рыбке» — хотелки растут от нового корыта до поста Владычицы морской быстрее, чем успеваешь реализовать ранее согласованное — а тут уж ни в сказке сказать, ни акт подписать.

Ну и, отвечая на вопрос из заголовка, скажу крамольное — на мой взгляд такая разработка (по методологии SCRUM или вообще по принципам Agile) всё же не проект, а процесс. И эта методология (и подход), безусловно, хороша, а иногда и единственно приемлема — но только там и тогда, где высока степень неопределённости и рамки не ограничены (вспоминаем одну из ценностей Agile, на которых зиждется и методология Scrum); но, с другой стороны, эта методология именно в силу своей гибкости противоречит вышеупомянутым свойствам проекта, а значит, для проектов с фиксированными сроками и ценой применять её не стОит. Тем более, что и с документацией не всё будет гладко (опять же, смотрим принципы и ценности Agile), хотя бы потому, что документы, созданные на разных этапах, могут не сойтись — ТЗ, ПМИ и технорабочий проект, которые почти всегда требуют госзаказчики, внезапно могут противоречить друг другу.