Разработка по SCRUM - это проект?
Итак, что такое «разработка продукта»? Проект? Процесс? Функция?
Однозначного ответа на этот вопрос, скорее всего, нет. И вот почему.
Начнём с определения проекта. Что такое «проект»? По PMBoK («библия» проектного менеджмента) проектом считается «временное предприятие, направленное на создание уникального продукта, услуги или результата», и характеризуется проект тем, что он:
- временный, т.е. имеет чёткие временнЫе рамки (начало/конец), и, как правило, заранее определённые ресурсы;
- уникальный, т.е. в рамках проекта создаются уникальные результаты;
- последовательный (вспомним WBS и диаграмму Гантта) — т.е. любой проект состоит из чёткой, заранее определённой последовательности работ.
Если этого нет, то это уже не проект, а процесс.
Но процесс может быть предопределённым (2+ уровень зрелости бизнес-процессов в организации), либо стохастическим (ad hoc). Серийное производство, типизированные процессы, не имеющие при этом чётких временнЫх рамок — это не проект. К таким можно отнести некоторые этапы ЖЦ создания продукта (например, техподдержка первого уровня после запуска в постоянную эксплуатацию, или функции бэк-офиса)
В моей практике были и процессы (например, мы делали, параллельно исследуя и разрабатывая «что делать» и «как делать», принципиально новую информационную систему — я тогда работал в отраслевом НИИ, шла работа по созданию АСУ отрасли, «всё было впервые и вновь», у нас был блок аналитики данных, и мы последовательно добавляли всё новый функционал, о возможности создания которого ещё недавно даже не думали), и проекты (например, разработка веб сайтов в веб-студии — уже после того, как ушёл из НИИ). Там не было чётких временных рамок, не считая некоторых нюансов оформления НИР — сроки и смета, конечно, были, и были некие промежуточные артефакты типа работающего ПО и документации, но требования к ним явным образом не предъявлялись, кроме того, что они должны быть; сам же «проект» продлевался из года в год — и это было нормально и правильно, потому что это была тематика лаборатории.
Была и разработка (как процесс) внутрикорпоративной ERP на 1С в компании, где я работал после НИИ — к моему счастью, там я уже не программировал и даже не проектировал архитектуру продукта, за мной была только постановка задачи и соучастие («C» в матрице ответственности RACI) в проектировании решения. К не меньшему счастью, обходились и без выходной документации (для себя же!). Там тоже не было временнЫх границ — только локальные «недодедлайны», да приоритезация задач. Сколько фирма жила (ну, не с самого рождения, конечно), столько и делался продукт. Последовательно «обрастая мясом».
А вот сейчас, задним числом, думаю — какую методологию можно было (бы) подтянуть под такие РАБОТЫ (проекты, процессы): где лучше скрам, где водопад? И, честно говоря, не готов однозначно сказать. Хотя по матрице Стейси и модели Кеневин (Cynefin) примерно понимаю, какой проект/процесс где должен был бы быть.
Но если речь всё же о проектах, то (возраст, что ли, сказывается, или привычки?) я бы предпочёл всё же водопад. Или RUP. Сознательно выделив блок анализа в отдельный «предпроектный» проект с фиксацией (с заказчиком) договорённостей и выявленных требований в виде ТЗ (по которому потом и ПМИ написать, и приёмку пройти можно).
Ведь по той же модели Кеневин, SCRUM хорош в том квадранте («пятую ногу» в виде нахлобучки «всё вместе по чуть-чуть» не берём), где ещё нет хаоса, но уже есть некая неопределённость, когда в начале работы нельзя точно сказать, что мы хотим получить в итоге.
Если признать и принять неопределённость (что, зачастую, скорей, политическое решение, нежели объективно обусловленное), то — да, наверно, лучше аджайл со скрамом.
Но вот вопрос (тут снова к управленческому консалтингу и стратегическому планированию, даже ещё выше — к миссии и ценностям, как ни странно): а всегда ли надо принимать неопределённость как априорную и непреложную данность, или это только наше нежелание навести порядок? Опыт подсказывает — иногда достаточно чуть жёстче поставить себя с заказчиком, не давая ему вольности для вариативности, чтобы упростить работу и гарантированно сделать именно то, что заказчику нужно, и сдать ему это в срок и к обоюдному удовольствию. Иначе будет, как у Пушкина в «Сказке о рыбаке и рыбке» — хотелки растут от нового корыта до поста Владычицы морской быстрее, чем успеваешь реализовать ранее согласованное — а тут уж ни в сказке сказать, ни акт подписать.
Ну и, отвечая на вопрос из заголовка, скажу крамольное — на мой взгляд такая разработка (по методологии SCRUM или вообще по принципам Agile) всё же не проект, а процесс. И эта методология (и подход), безусловно, хороша, а иногда и единственно приемлема — но только там и тогда, где высока степень неопределённости и рамки не ограничены (вспоминаем одну из ценностей Agile, на которых зиждется и методология Scrum); но, с другой стороны, эта методология именно в силу своей гибкости противоречит вышеупомянутым свойствам проекта, а значит, для проектов с фиксированными сроками и ценой применять её не стОит. Тем более, что и с документацией не всё будет гладко (опять же, смотрим принципы и ценности Agile), хотя бы потому, что документы, созданные на разных этапах, могут не сойтись — ТЗ, ПМИ и технорабочий проект, которые почти всегда требуют госзаказчики, внезапно могут противоречить друг другу.
P.S. Про документацию будет отдельный большой пост. И, скорее всего, не один.