Поздравляю, Вы созрели для перехода в бизнес-консалтинг. Ну или, как минимум, в ИТ-менеджмент (в стратегическое руководство ИТ-компаниями - CEO/CTO, в крайнем случае - CIO, хотя это и немного в сторону).
О, да, знакомо! Сам себе и аналитик (бизнес+системный), и архитектор, и дизайнер интерфейса, и программист, и сисадмин, и техпис, и менеджер проекта, и разработчик программы обучения пользователей, и техподдержка, и ведущий тренинга по пользованию продуктом (особенно, когда люди компьютера избегать стараются, ибо боятся - это я про ранние 90-е и работников тогдашней старой гвардии 50+), и... В общем, "и жнец, и швец, и в дуду игрец".
Про НСИ надо учитывать два момента. Информационная база, в состав которой входит и НСИ, состоит из внемашинной и внутримашинной. Внемашинная включает в себя классификаторы и кодификаторы, определяемые вне системы. Например, семейство классификаторов (ОКПО, ОКОНХ, ОКВЭД, ОКОПФ, ОКСМ, ОКАТО и т.п.). За их ведение отвечают внешние структуры. Вопрос только в том, кто, как и когда их превращает во внутримашинную форму. Но задача интеграции может стоять отдельно, и она двоякая - организационная и техническая. Да, хорошо, если это изначально прописано в ТЗ.
Но есть и локальные справочники, которые делятся на вне машинные данные и на внутримашинные. Их можно вести либо в самой системе, либо также делать интеграцию с той системой, которая для этого справочника первична. И тут, конечно, тоже хорошо БЫ прописать это в ТЗ. Но чаще бывает, что это делается на этапе проектирования (я сторонник водопада), т.е. на этапе создания ТЗ формулируются только общие требования, а реализация отдаётся на откуп разработчикам - соответственно, результаты отражаются в документации техно-рабочего проекта.
Про ТЗ и проект ещё хочу сказать. Дело в том, что ТЗ хорошо там, где есть проект, т.е. чёткая спецификация требований и чёткие сроки. Иначе это процесс (и там работает, кстати, скрам), но ТЗ по нему написать практически невозможно - в лучшем случае бриф, из которого делается бэклог
1. Если речь про ТЗ, то надо уточнить, на что это ТЗ? На систему, на программу или на работу?
ТЗ на систему - это, скорее всего, ГОСТ 34.602.
Если на программу - то, скорее всего, по ГОСТ 19.201.
Если на работу, то стандартов общепринятых нет.
2. Упомянуты 44-фз и 223-фз. Это госзакупки. Работы по ним ведутся в формате проекта, т.е. есть фиксированный бюджет и фиксированные сроки. А это, извините, водопад, т.е. ГОСТ 34.601 (теперь ГОСТ Р 59793). Тем более, что госзаказчики (а кто ещё по 44-фз и 223-фз работает?) любят ГОСТы. Значит, забываем скрам, спринты, бэклоги и прочее. Да и скрам, как методология, основанная на принципах аджайл, не должна работать ни с ТЗ, ни с документацией (вспоминаем два из четырёх базовых постулата аджайл про документацию vs. продукт и гибкость vs. первоначальные договорённости).
Ну и про термин ЧТЗ. Не в смысле "челябинский тракторный завод", а "частное техническое задание". Это ТЗ на часть системы (открываем ГОСТ 34.602, п. 3.3), а не доп.ТЗ (п.3.5 в том же ГОСТ 34.602). Да, традиция, мы все привыкли, но в оригинале значение акронима было другое.
Ну и главное не сказано. На основе ТЗ (со всеми ЧТЗ и доп ТЗ кумулятивно) должны писаться ПМИ (на основе которой идёт приёмка) и документация (техно-рабочий проект). А как иначе проверить, что исходная постановка реализована вообще и реализована правильно, и готовый продукт удовлетворяет предъявляемым к нему требованиям?
Видел. И делал. Подходя по принципу из советского мультика - "лучше день потерять, зато потом за пять минут долететь". В смысле, уделял достаточно внимания и сил сбору и согласованию требований, а потом и проектированию.
Да, несколько раз заказчику "приходил аппетит во время еды", который трансформировался в допсоглашения с допТЗ.
Правда, признаюсь, таких случаев было немного 🤷♂️. За мои 33 года работы.
Разница "проекта" и "процесса" заключается в том, что процесс [условно] непрерывен, не имеет чёткого срока окончания (может тянуться годами под предлогом PDCA и адаптации под изменяющиеся условия), а проект имеет чёткие сроки, чётко обозначенные границы, чёткое ИЗНАЧАЛЬНОЕ представление о том, что собой должен представлять целевой продукт (т.е. иметь априори известные номенклатуру и значения свойств). Хотя да, процесс можно разбить на проекты - сделали один релиз (смотрим тендеры и госзакупки - там именно проекты, но никто не мешает из года в год заказывать "модернизацию" ранее созданного).
И в таком контексте неважно, HARDware это или SOFTware. Хотя да, ПО даёт несколько больше свободы для поставки потребителю "минимально ценного продукта" (того самого MVP), с которым потребитель УЖЕ может работать.
Правда, если потом выяснится, что принятые на ранних этапах концептуальные архитектурные решения не соответствуют текущему набору требований, то... будет больно...
Да, Вы правы, в ряде случаев аджайл может работать, и даже окажется единственным приемлемым для конкретного случая (осознанно не говорю "проекта") способом организации работ.
Больше того, в стародавние времена (ещё а прошлом веке 😎) я использовал, сам того не зная, принципы аджайл и даже что-то подобное скраму с канбан-досками, внутри этапов водопада.
Но переход уровня в ряде случаев критически важен. Если это проект.
А если процесс - то да, скрам подойдёт. Только процесс проектом называть не надо. И да, процесс, как непрерывный и во времени не ограниченный поток работ с заранее неизвестным результатом, как раз и предполагает гибкость, и потому вполне укладывается в цикл PDCA Шухарта-Деминга.
Очень интересный и правильный разбор ситуации. Могу оценить с обеих позиций - и с точки зрения нанимателя/руководителя, работавшего как с штатными подчинёнными, так и с удалёнщиками, и с точки зрения наёмного сотрудника, опять же, как штатника, так и удалёнщика.
Удалённый формат работы без микроменеджмента, но с чёткой постановкой задач и грамотной организацией взаимодействия, даёт уникальные возможности построить распределённую команду из разных регионов (и даже стран), где люди будут работать в комфортной для себя среде, в комфортном режиме, что повышает и результативность, и эффективность, и качество продукта (да и процесса, хотя в этом некоторые видят парадокс). Тем более, что сейчас, как совершенно правильно в заметке отмечено, есть очень богатый выбор онлайн-инструментов для организации работы и обмена информацией в необходимом формате.
Да, иногда хорошо, полезно и в чём-то приятно поработать в офисе - что ж, если удобней и привычней, можно и в офисе. Кому удобней дома - пусть работает дома (если трудовая функция и режим это позволяют - понятно, что работы, требующие присутствия на рабочем месте, как технологически, так и организационно, например, над проектами с грифом секретности выше "ДСП", возможность применения удалёнки ограничивают). Тут и больничный брать не надо, если силы есть думать и с компьютером работать, и в транспорте не мучиться по часу в толпе в час пик, и в пробках дорожных не торчать, и много других преимуществ.
Главное, чтобы результат и сроки не страдали. А это зависит не от того, где находится участник процесса, а от того, как процесс и управление им, а также коммуникации между членами команды организованы.
В общем, я за удалёнку или гибрид. Хотя из 30+ лет стажа более 20 проработал в офисе.
Железку нельзя изменить, когда она уже изготовлена. Хотя как сказать... Можно "тюнинговать" (что мы часто видим на примере автомобилей). А выпустить новую по обновлённым чертежам и техкартам можно легко.
С софтом почти так. Если говорить о релизах - то они сравнимы с железками. Только несколько проще софт переделать, чем железку. Но, если по-честному, новый релиз софта - это, де-факто, новая "железка".
НО! Всё зависит от того, до какой степени изменять и железку, и софт (и дом).
Кто мешает на автомобиле, например, снять штатные детали и поставить, как минимум, совместимые (по посадочным местам, габаритам, характеристикам), как максимум - переделать под нужные?
Кто мешает снять с компьютера один компонент и заменить на другой (хард сменить на SSD, или заменить видеокарту на совместимую, заменить планку памяти и т.п.), НЕ МЕНЯЯ архитектуру?
Кто мешает в доме заменить обои, розетки (не перенося их), люстру?
А вот если задача КАРДИНАЛЬНО переделать - то тут и с железом, и с софтом проблемы будут.
Пример. Была сделана для одного крупного общероссийского межрегионального проекта СХД, в которой данные ежедневно трансформировались в витрину данных, дополняя "исторические" данные оперативными прошедшего дня. Всё было рассчитано так изначально (и протестировано на "фыве"), что за время ночи (от закрытия дня в Калининграде до начала рабочего дня в Петропавловске-Камчатском) данные должны успеть преобразоваться. Работа на реальных данных показало, что "не сезон". Пришлось переделывать. Полностью. Модель данных. После того, как система пошла в опытную эксплуатацию.
Причём требования "в процессе пути" не менялись, т.е. "собачка не могла подрасти". И НИЧТО не мешало аналитикам и архитекторам СНАЧАЛА подумать, потом делать.
Резюме. Да здравствует водопад там, где он должен здравствовать!
С этим бы я не спорил. Но именно в том и проблема (проверено на многих проектах, где я был, увы, не ПМ, который не допустит такого, а лишь аналитиком), что аппетит к заказчику приходит в процессе. И да, я сторонник водопада для крупных проектов. Именно проектов, а не процессов, и не штучной разработки с неизвестными требованиями к результату - там да, по Кенеди или Стейси лучше скрам.
Предположим, что мы делаем не информационную систему, а строим дом. Какой MVP можно дать заказчику после одного витка (спринта)? Если у заказчика выросли хотелки по тем этапам, которые уже прошли (не обои выбрать, пока ещё стены строим, а площадь застройки, планировку конфигурацию инженерных сетей поменять, когда уже крыша готова и обои наклеены) - принять поправки в бэклог? 😉
В сопромате ("Сопротивление материалов") есть такая штука, как "статически неопределимые задачи". Это задачи, которые нельзя решить в лоб, потому что получается взаимное влияние расчётных данных (типа циклически замкнутой самой на себя ссылки в Excel).
Но для их решения придумали трюк - искусственное виртуальное введение лишней степени свободы, которая позволяет упростить модель и сделать задачу статически определимой, которая уже легко и тривиально решается стандартными для сопромата методами.
Мне кажется, в ситуации с неопределённостью "что делать" и "как делать" правильнее было бы, аналогично трюку из сопромата, понижать степень неопределённости, и сделать это именно выделением этапов исследования "что делать" и "как делать" - собственно, в "водопаде" так и сделано, что позволяет выстроить поступательную цепочку.
Но тут мы, наверно, уйдём немного в другую сферу, в область управленческого консалтинга, выбора подхода (проектный/процессный[/функциональный]), оргструктур, целей и показателей их достижения (KPI/OKR).
Что такое "разработка продукта"? Проект? Процесс? Функция? Однозначного ответа нет.
Что есть "проект"? По PMBoK проектом считается "временное предприятие, направленное на создание уникального продукта, услуги или результата", и характеризуется тем, что он:
временный, т.е. имеет чёткие временные рамки (начало/конец), и, как правило, заранее определённые ресурсы;
уникальный, т.е. в рамках проекта создаются уникальные результаты;
последовательный (вспомним WBS и диаграмму Гантта) - т.е. любой проект состоит из чёткой, заранее определённой последовательности работ.
Если этого нет, то это уже не проект - а процесс.
Но процесс может быть предопределённым (2+ уровень зрелости бизнес-процессов в организации), либо стохастическим (ad hoc). Серийное производство, типизированные процессы, не имеющие при этом чётких временнЫх рамок - это не проект. К таким можно отнести некоторые этапы ЖЦ создания продукта (например, техподдержка первого уровня после запуска в постоянную эксплуатацию, или функции бэк-офиса)
У меня были в практике и процессы (например, делали, параллельно исследуя и разрабатывая "что делать" и "как делать", принципиально новую информационную систему - я работал в отраслевом НИИ, шла работа по созданию АСУ отрасли, "всё было впервые и вновь", у нас был блок аналитики, и мы последовательно добавляли всё новый функционал, о возможности которого ещё год назад даже не думали), и проекты (например, разработка веб сайтов в веб-студии - уже после того, как ушёл из НИИ).
Была и разработка (как процесс) внутрикорпоративной ERP на 1С - к моему счастью, там я уже не программировал и даже не проектировал архитектуру продукта, за мной была только постановка задачи и соучастие ("C" в RACI) в проектировании решения. К не меньшему счастью, обходились и без выходной документации (для себя же!). Там тоже не было временнЫх границ - только локальные "недодедлайны", да приоритезация задач. Сколько фирма жила (ну, не с самого рождения, конечно), столько и делался продукт. Последовательно "обрастая мясом".
А вот сейчас, задним числом, думаю - какую методологию можно было (бы) подтянуть под такие РАБОТЫ (проекты, процессы): где лучше скрам, где водопад? И, честно говоря, не готов однозначно сказать. Хотя по матрице Стейси и модели Кеневин примерно понимаю, какой проект/процесс где должен был бы быть.
Но если речь всё же о проектах, то (возраст, что ли, сказывается, или привычки?) я бы предпочёл всё же водопад. Сознательно выделив блок анализа в отдельный "предпроектный" проект с фиксацией (с заказчиком) договорённостей и выявленных требований в виде ТЗ (по которому потом и ПМИ написать, и приёмку пройти можно).
Потому что если признать и принять неопределённость (что, скорей, политическое решение, нежели объективно обусловленное), то - да, наверно, лучше аджайл со скрамом. Но вот вопрос (тут снова к управленческому консалтингу и стратегическому планированию, даже ещё выше - к миссии и ценностям, как ни странно): а всегда ли надо принимать неопределённость как априорную и непреложную данность, или это только наше нежелание навести порядок? Опыт подсказывает - иногда достаточно чуть жёстче поставить себя с заказчиком, не давая ему вольности для вариативности, чтобы упростить работу и гарантированно сделать именно то, что заказчику нужно, и сдать ему это в срок и к обоюдному удовольствию. Иначе будет, как у Пушкина в "Сказке о рыбаке и рыбке" - хотелки растут от нового корыта до поста Владычицы морской быстрее, чем успеваешь реализовать ранее согласованное - а тут уж ни в сказке сказать, ни акт подписать.
Главное, ночью в темноте такое не встретить...
Поздравляю, Вы созрели для перехода в бизнес-консалтинг. Ну или, как минимум, в ИТ-менеджмент (в стратегическое руководство ИТ-компаниями - CEO/CTO, в крайнем случае - CIO, хотя это и немного в сторону).
В сухом остатке "импортозамещение" обернулось острой потребностью в экстренном затыкании образовавшихся дыр.
Ну хорошо, обучим мы армию "специалистов" перенастройке винды на линукс и миграции с оракла и мс-сиквел на постгрес.
А дальше что, лет через 5-10?
О, да, знакомо! Сам себе и аналитик (бизнес+системный), и архитектор, и дизайнер интерфейса, и программист, и сисадмин, и техпис, и менеджер проекта, и разработчик программы обучения пользователей, и техподдержка, и ведущий тренинга по пользованию продуктом (особенно, когда люди компьютера избегать стараются, ибо боятся - это я про ранние 90-е и работников тогдашней старой гвардии 50+), и... В общем, "и жнец, и швец, и в дуду игрец".
Зато какая закалка! Какой опыт!
Спасибо за развёрнутый комментарий!
Про НСИ надо учитывать два момента. Информационная база, в состав которой входит и НСИ, состоит из внемашинной и внутримашинной. Внемашинная включает в себя классификаторы и кодификаторы, определяемые вне системы. Например, семейство классификаторов (ОКПО, ОКОНХ, ОКВЭД, ОКОПФ, ОКСМ, ОКАТО и т.п.). За их ведение отвечают внешние структуры. Вопрос только в том, кто, как и когда их превращает во внутримашинную форму. Но задача интеграции может стоять отдельно, и она двоякая - организационная и техническая. Да, хорошо, если это изначально прописано в ТЗ.
Но есть и локальные справочники, которые делятся на вне машинные данные и на внутримашинные. Их можно вести либо в самой системе, либо также делать интеграцию с той системой, которая для этого справочника первична. И тут, конечно, тоже хорошо БЫ прописать это в ТЗ. Но чаще бывает, что это делается на этапе проектирования (я сторонник водопада), т.е. на этапе создания ТЗ формулируются только общие требования, а реализация отдаётся на откуп разработчикам - соответственно, результаты отражаются в документации техно-рабочего проекта.
Про ТЗ и проект ещё хочу сказать. Дело в том, что ТЗ хорошо там, где есть проект, т.е. чёткая спецификация требований и чёткие сроки. Иначе это процесс (и там работает, кстати, скрам), но ТЗ по нему написать практически невозможно - в лучшем случае бриф, из которого делается бэклог
После прочтения появилось много вопросов.
1. Если речь про ТЗ, то надо уточнить, на что это ТЗ? На систему, на программу или на работу?
ТЗ на систему - это, скорее всего, ГОСТ 34.602.
Если на программу - то, скорее всего, по ГОСТ 19.201.
Если на работу, то стандартов общепринятых нет.
2. Упомянуты 44-фз и 223-фз. Это госзакупки. Работы по ним ведутся в формате проекта, т.е. есть фиксированный бюджет и фиксированные сроки. А это, извините, водопад, т.е. ГОСТ 34.601 (теперь ГОСТ Р 59793). Тем более, что госзаказчики (а кто ещё по 44-фз и 223-фз работает?) любят ГОСТы. Значит, забываем скрам, спринты, бэклоги и прочее. Да и скрам, как методология, основанная на принципах аджайл, не должна работать ни с ТЗ, ни с документацией (вспоминаем два из четырёх базовых постулата аджайл про документацию vs. продукт и гибкость vs. первоначальные договорённости).
Ну и про термин ЧТЗ. Не в смысле "челябинский тракторный завод", а "частное техническое задание". Это ТЗ на часть системы (открываем ГОСТ 34.602, п. 3.3), а не доп.ТЗ (п.3.5 в том же ГОСТ 34.602). Да, традиция, мы все привыкли, но в оригинале значение акронима было другое.
Ну и главное не сказано. На основе ТЗ (со всеми ЧТЗ и доп ТЗ кумулятивно) должны писаться ПМИ (на основе которой идёт приёмка) и документация (техно-рабочий проект). А как иначе проверить, что исходная постановка реализована вообще и реализована правильно, и готовый продукт удовлетворяет предъявляемым к нему требованиям?
Раз у нас, судя по вчерашним новостям, создают министерство по искусственному интеллекту, впору массово заменять капчу на тест Тьюринга.
"Докажите, что Вы не робот" (с) 🤣
"Лучшая работа - это высокооплачиваемое хобби" (с).
Не всем, правда, с этим везёт.
Видел. И делал. Подходя по принципу из советского мультика - "лучше день потерять, зато потом за пять минут долететь". В смысле, уделял достаточно внимания и сил сбору и согласованию требований, а потом и проектированию.
Да, несколько раз заказчику "приходил аппетит во время еды", который трансформировался в допсоглашения с допТЗ.
Правда, признаюсь, таких случаев было немного 🤷♂️. За мои 33 года работы.
Разница "проекта" и "процесса" заключается в том, что процесс [условно] непрерывен, не имеет чёткого срока окончания (может тянуться годами под предлогом PDCA и адаптации под изменяющиеся условия), а проект имеет чёткие сроки, чётко обозначенные границы, чёткое ИЗНАЧАЛЬНОЕ представление о том, что собой должен представлять целевой продукт (т.е. иметь априори известные номенклатуру и значения свойств). Хотя да, процесс можно разбить на проекты - сделали один релиз (смотрим тендеры и госзакупки - там именно проекты, но никто не мешает из года в год заказывать "модернизацию" ранее созданного).
И в таком контексте неважно, HARDware это или SOFTware. Хотя да, ПО даёт несколько больше свободы для поставки потребителю "минимально ценного продукта" (того самого MVP), с которым потребитель УЖЕ может работать.
Правда, если потом выяснится, что принятые на ранних этапах концептуальные архитектурные решения не соответствуют текущему набору требований, то... будет больно...
Да, Вы правы, в ряде случаев аджайл может работать, и даже окажется единственным приемлемым для конкретного случая (осознанно не говорю "проекта") способом организации работ.
Больше того, в стародавние времена (ещё а прошлом веке 😎) я использовал, сам того не зная, принципы аджайл и даже что-то подобное скраму с канбан-досками, внутри этапов водопада.
Но переход уровня в ряде случаев критически важен. Если это проект.
А если процесс - то да, скрам подойдёт. Только процесс проектом называть не надо. И да, процесс, как непрерывный и во времени не ограниченный поток работ с заранее неизвестным результатом, как раз и предполагает гибкость, и потому вполне укладывается в цикл PDCA Шухарта-Деминга.
Очень интересный и правильный разбор ситуации. Могу оценить с обеих позиций - и с точки зрения нанимателя/руководителя, работавшего как с штатными подчинёнными, так и с удалёнщиками, и с точки зрения наёмного сотрудника, опять же, как штатника, так и удалёнщика.
Удалённый формат работы без микроменеджмента, но с чёткой постановкой задач и грамотной организацией взаимодействия, даёт уникальные возможности построить распределённую команду из разных регионов (и даже стран), где люди будут работать в комфортной для себя среде, в комфортном режиме, что повышает и результативность, и эффективность, и качество продукта (да и процесса, хотя в этом некоторые видят парадокс). Тем более, что сейчас, как совершенно правильно в заметке отмечено, есть очень богатый выбор онлайн-инструментов для организации работы и обмена информацией в необходимом формате.
Да, иногда хорошо, полезно и в чём-то приятно поработать в офисе - что ж, если удобней и привычней, можно и в офисе. Кому удобней дома - пусть работает дома (если трудовая функция и режим это позволяют - понятно, что работы, требующие присутствия на рабочем месте, как технологически, так и организационно, например, над проектами с грифом секретности выше "ДСП", возможность применения удалёнки ограничивают). Тут и больничный брать не надо, если силы есть думать и с компьютером работать, и в транспорте не мучиться по часу в толпе в час пик, и в пробках дорожных не торчать, и много других преимуществ.
Главное, чтобы результат и сроки не страдали. А это зависит не от того, где находится участник процесса, а от того, как процесс и управление им, а также коммуникации между членами команды организованы.
В общем, я за удалёнку или гибрид. Хотя из 30+ лет стажа более 20 проработал в офисе.
Железку нельзя изменить, когда она уже изготовлена. Хотя как сказать... Можно "тюнинговать" (что мы часто видим на примере автомобилей). А выпустить новую по обновлённым чертежам и техкартам можно легко.
С софтом почти так. Если говорить о релизах - то они сравнимы с железками. Только несколько проще софт переделать, чем железку. Но, если по-честному, новый релиз софта - это, де-факто, новая "железка".
НО! Всё зависит от того, до какой степени изменять и железку, и софт (и дом).
Кто мешает на автомобиле, например, снять штатные детали и поставить, как минимум, совместимые (по посадочным местам, габаритам, характеристикам), как максимум - переделать под нужные?
Кто мешает снять с компьютера один компонент и заменить на другой (хард сменить на SSD, или заменить видеокарту на совместимую, заменить планку памяти и т.п.), НЕ МЕНЯЯ архитектуру?
Кто мешает в доме заменить обои, розетки (не перенося их), люстру?
А вот если задача КАРДИНАЛЬНО переделать - то тут и с железом, и с софтом проблемы будут.
Пример. Была сделана для одного крупного общероссийского межрегионального проекта СХД, в которой данные ежедневно трансформировались в витрину данных, дополняя "исторические" данные оперативными прошедшего дня. Всё было рассчитано так изначально (и протестировано на "фыве"), что за время ночи (от закрытия дня в Калининграде до начала рабочего дня в Петропавловске-Камчатском) данные должны успеть преобразоваться. Работа на реальных данных показало, что "не сезон". Пришлось переделывать. Полностью. Модель данных. После того, как система пошла в опытную эксплуатацию.
Причём требования "в процессе пути" не менялись, т.е. "собачка не могла подрасти". И НИЧТО не мешало аналитикам и архитекторам СНАЧАЛА подумать, потом делать.
Резюме. Да здравствует водопад там, где он должен здравствовать!
Спиральная методология Боэма?
https://ru.wikipedia.org/wiki/Спиральная_модель
А это уже поисковая работа, НИР (НИОКР) 😎
Вот тут только гибкие методологии и работают
Требования меняются потому, что:
Изначально требований никто не знает (вопрос к аналитикам...)
Руководство (ПМ, руководители компании) допускают вариативность требований, значительно меняющих длительность и ресурсоëмкость работы.
Вот только во втором случае это уже не проект, если следовать определению понятия "проект" 🤷♂️
С этим бы я не спорил. Но именно в том и проблема (проверено на многих проектах, где я был, увы, не ПМ, который не допустит такого, а лишь аналитиком), что аппетит к заказчику приходит в процессе. И да, я сторонник водопада для крупных проектов. Именно проектов, а не процессов, и не штучной разработки с неизвестными требованиями к результату - там да, по Кенеди или Стейси лучше скрам.
Согласен почти со всем, кроме одного.
Почему позволили собачке подрасти?
Предположим, что мы делаем не информационную систему, а строим дом. Какой MVP можно дать заказчику после одного витка (спринта)? Если у заказчика выросли хотелки по тем этапам, которые уже прошли (не обои выбрать, пока ещё стены строим, а площадь застройки, планировку конфигурацию инженерных сетей поменять, когда уже крыша готова и обои наклеены) - принять поправки в бэклог? 😉
В сопромате ("Сопротивление материалов") есть такая штука, как "статически неопределимые задачи". Это задачи, которые нельзя решить в лоб, потому что получается взаимное влияние расчётных данных (типа циклически замкнутой самой на себя ссылки в Excel).
Но для их решения придумали трюк - искусственное виртуальное введение лишней степени свободы, которая позволяет упростить модель и сделать задачу статически определимой, которая уже легко и тривиально решается стандартными для сопромата методами.
Мне кажется, в ситуации с неопределённостью "что делать" и "как делать" правильнее было бы, аналогично трюку из сопромата, понижать степень неопределённости, и сделать это именно выделением этапов исследования "что делать" и "как делать" - собственно, в "водопаде" так и сделано, что позволяет выстроить поступательную цепочку.
Но тут мы, наверно, уйдём немного в другую сферу, в область управленческого консалтинга, выбора подхода (проектный/процессный[/функциональный]), оргструктур, целей и показателей их достижения (KPI/OKR).
Что такое "разработка продукта"? Проект? Процесс? Функция? Однозначного ответа нет.
Что есть "проект"? По PMBoK проектом считается "временное предприятие, направленное на создание уникального продукта, услуги или результата", и характеризуется тем, что он:
временный, т.е. имеет чёткие временные рамки (начало/конец), и, как правило, заранее определённые ресурсы;
уникальный, т.е. в рамках проекта создаются уникальные результаты;
последовательный (вспомним WBS и диаграмму Гантта) - т.е. любой проект состоит из чёткой, заранее определённой последовательности работ.
Если этого нет, то это уже не проект - а процесс.
Но процесс может быть предопределённым (2+ уровень зрелости бизнес-процессов в организации), либо стохастическим (ad hoc). Серийное производство, типизированные процессы, не имеющие при этом чётких временнЫх рамок - это не проект. К таким можно отнести некоторые этапы ЖЦ создания продукта (например, техподдержка первого уровня после запуска в постоянную эксплуатацию, или функции бэк-офиса)
У меня были в практике и процессы (например, делали, параллельно исследуя и разрабатывая "что делать" и "как делать", принципиально новую информационную систему - я работал в отраслевом НИИ, шла работа по созданию АСУ отрасли, "всё было впервые и вновь", у нас был блок аналитики, и мы последовательно добавляли всё новый функционал, о возможности которого ещё год назад даже не думали), и проекты (например, разработка веб сайтов в веб-студии - уже после того, как ушёл из НИИ).
Была и разработка (как процесс) внутрикорпоративной ERP на 1С - к моему счастью, там я уже не программировал и даже не проектировал архитектуру продукта, за мной была только постановка задачи и соучастие ("C" в RACI) в проектировании решения. К не меньшему счастью, обходились и без выходной документации (для себя же!). Там тоже не было временнЫх границ - только локальные "недодедлайны", да приоритезация задач. Сколько фирма жила (ну, не с самого рождения, конечно), столько и делался продукт. Последовательно "обрастая мясом".
А вот сейчас, задним числом, думаю - какую методологию можно было (бы) подтянуть под такие РАБОТЫ (проекты, процессы): где лучше скрам, где водопад? И, честно говоря, не готов однозначно сказать. Хотя по матрице Стейси и модели Кеневин примерно понимаю, какой проект/процесс где должен был бы быть.
Но если речь всё же о проектах, то (возраст, что ли, сказывается, или привычки?) я бы предпочёл всё же водопад. Сознательно выделив блок анализа в отдельный "предпроектный" проект с фиксацией (с заказчиком) договорённостей и выявленных требований в виде ТЗ (по которому потом и ПМИ написать, и приёмку пройти можно).
Потому что если признать и принять неопределённость (что, скорей, политическое решение, нежели объективно обусловленное), то - да, наверно, лучше аджайл со скрамом. Но вот вопрос (тут снова к управленческому консалтингу и стратегическому планированию, даже ещё выше - к миссии и ценностям, как ни странно): а всегда ли надо принимать неопределённость как априорную и непреложную данность, или это только наше нежелание навести порядок? Опыт подсказывает - иногда достаточно чуть жёстче поставить себя с заказчиком, не давая ему вольности для вариативности, чтобы упростить работу и гарантированно сделать именно то, что заказчику нужно, и сдать ему это в срок и к обоюдному удовольствию. Иначе будет, как у Пушкина в "Сказке о рыбаке и рыбке" - хотелки растут от нового корыта до поста Владычицы морской быстрее, чем успеваешь реализовать ранее согласованное - а тут уж ни в сказке сказать, ни акт подписать.