Комментарии 4
Пара комментариев про непонятки:
Похоже, у Вас путаница заказчика и пользователя. В частности:
По оси X отложена оценка готовности пользователя к приемке
Ну как-бы НЕ пользователь осуществляет приёмку. И в остальном также: согласно статье пользователи становятся немного ответственными за проект? Да, конечно, такие подходы есть, но это совсем не обязательно.
Какое-то странное отношение к приёмке (и к качеству в целом). Выдавать на приёмку заказчику (согласно программе методике испытаний) сырое ПО - ну это такое себе приключение. Тем более, если есть методика испытаний, то компания-разработчик САМА прогоняет свой продукт и получает "обратную" связь. Зачем для этого привлекать заказчика/пользователя/ещёкогото?
Смешивание проекта и продукта, потом разведение их по разным углам. ? Ну как-бы проект (у него есть определение) это ДЕЯТЕЛЬНОСТЬ. причём не всякая.
Сарказм: даже такая шутка есть: вы каждый день по утрам достаёте батончик колбасы и нарезаете его на ломтики, чтобы сделать себе бутерброды. Нарезание на ломтики - это проект?Деятельность, ограниченная по времени, уникальный результат, каждый день разное.
Или, в качестве параллели, из ИТ мира: вы каждый день играете в контру. Разные карты, разные команды, время разное ... но ограниченное. Результат тоже уникальный. Игра в контру - это проект?
/сарказм.
Пара комментариев про предложения:
Возможно, стоит Вашу статью оформить в виде:
Вот есть способ ведения проекта с прицелом на определённую специфику (которой у Вас много: только ИТ, общение с пользователями, возможность показа отдельных/изолированных фич (например: когда у вас нет готового условного Word-а, то показывать (например) редактор формул с печатью может быть затруднительно) и много другого), с прицелом на жизненный цикл продукта.
Этот способ помог мне реализовать проекты такого типа. Жизненный цикл выстроился так-то. Указанный способ отличается от широко известных методик (agile/scrum, инкремент, waterfall, rad, и др.) тем-то и тем-то.
Вы подняли несколько интересных вопросов, касающихся различия между заказчиком и пользователем, а также роли каждого из них в процессе приемки. Я согласен, что в идеале разработчик должен проводить тестирование и обеспечивать качество продукта перед передачей его заказчику. Однако, в некоторых случаях вовлечение пользователей может помочь выявить нюансы, которые не всегда заметны команде разработки. В разработке наукоемкого ПО это вполне общая практика.
Что касается смешивания понятий проекта и продукта, я понимаю вашу точку зрения. В статье я стремился показать, как различные подходы могут применяться в зависимости от контекста.
Можно узнать где вы получили свой опыт проектного менеджмента? Хочу понять в какой школе менеджмента отсутствует фаза планирования после инициирования, а сразу идёт выполнение
Об артефактах продуктовой разработки и командном взаимодействии