Определение содержания проекта (продукта) – трудоемкий процесс с результатом в виде детального описания, в которое упакованы практически все известные в бережливом производстве потери, такие как:
- Частично выполненная работа. Есть только описание, но еще ничего не работает.
- Перепроизводство. Значительная часть описанной функциональности включена в scope "на всякий случай", то есть никогда не будет использована.
- Повторное приобретение знания. Неявное знание на поздних этапах приходится получать заново.
- Передача работы. Описывают одни, реализуют другие.
- Задержки. Ожидание предварительной формализации по каждому изменению и уточнению.
- Дефекты. Верифицировать описание можно только работающим продуктом.
- Неиспользованный творческий потенциал сотрудников. Точнее его использование для деятельности не приносящей ценности.
Тем не менее, определить содержание проекта (продукта) нужно и желательно это сделать до начала проекта. И сделать это можно через ограничения, исключения и допущения.
Определение чего-то через отрицание - старая практика. В современной интерпретации наиболее последовательно представлена в философии негативного эмпиризма Карла Поппера.
Ключевым ограничением в нашем случае является то, что мы внедряем 1С:ERP/КА/УТ. Концентрация на одном продукте обеспечивает экспертизу в предмете, продукте и его внедрении, которая нужна для для быстрого определения содержания проекта.
Итак,
Ограничения:
- Перечисление входящих (не входящих) в проект подсистем 1C:ERP и явное указание на то, что типовая методология 1С:ERP не будет изменятся (в случае наличия типовой реализации), особенно это касается сложных расчетов и процессов (например, расчета себестоимости). Не нужно описывать реализацию этих подсистем – это за нас сделала фирма 1С в виде документации на ИТС, почти бесплатных курсов, аттестаций, вебинаров и т.д.
- Ограничения Заказчика. О них мы узнаем во время подготовки и проведения нулевого спринта. Это ограничения на ресурсы, сроки, географию и т.д.
Исключения:
- Явное перечисление всего, что не входит в проект. Помимо формирования правильных ожиданий Заказчика, целенаправленный поиск исключений, реализация которых могла бы сильно повлиять на результаты, сроки и бюджет проекта - это сама по себе полезная практика. Следуя Нассиму Талебу такие исключения можно назвать "черными лебедями" и их выявлению помогает экспертиза.
Черный лебедь – концепция Н.Талеба, включающая события, выпадающие из нашего горизонта планирования и моделирования, из-за низкой частоты появления, но могущие иметь значительные последствия.
Допущения:
- Это наши предположения об окружении проекта, на основе которых планируется проект.
Таким образом, очертить рамки проекта через ограничения, исключения и допущения можно достаточно быстро и с приемлемой точностью. А время и ресурсы, которое обычно тратятся на детальное описание, мы тратим на поставку MVP, готового к запуску у клиента.
Материал подготовил:
Евгений Салов, Product Owner, БИТ:ERP.
Поддержите нас лайками, если материал статьи оказался полезным для вас.
Читайте нас в телеграмме - https://t.me/bit_erp